Gestão de produtos de software - Como aumentar as chances de sucesso do seu software - Casa do Codigo

Prévia do material em texto

© Casa do Código
Todos os direitos reservados e protegidos pela Lei nº9.610, de 
10/02/1998.
Nenhuma parte deste livro poderá ser reproduzida, nem transmitida, sem 
autorização prévia por escrito da editora, aseja quais forem os meios: fo-
tográficos, eletrônicos, mecânicos, gravação ou quaisquer outros.
Edição
Adriano Almeida
Vivian Matsui
Revisão e diagramação
Bianca Hubert
Vivian Matsui
[2015]
Casa do Código
Livro para o programador
Rua Vergueiro, 3185 – 8º andar 
04101-300 – Vila Mariana – São Paulo – SP – Brasil
www.casadocodigo.com.br
5
Sobre gestão de 
produtos de software
Já chegamos àquele ponto no qual há software em lugares em que, há 
alguns anos, jamais imaginaríamos que haveria necessidade e utilidade 
de ter um software: televisão, geladeira, fogão, carro, relógio de pulso, 
óculos, roupa, fechadura, mesa, cadeira, equipamento médico e por aí 
vai. Isso sem falar no mais óbvio, o telefone que está em nossos bolsos 
ou bolsas e do qual estamos nos tornando cada vez mais dependentes.
A ubiquidade do software é hoje uma realidade, o software permeia 
inúmeras atividades e objetos de nosso dia a dia. Acredito que se pos-
sa dizer que 100% da população mundial tem suas vidas afetadas por 
software, e boa parte dessa população tem contato frequente com 
software. De acordo com o relatório We Are Social de 2015 (www.sli-
deshare.net/wearesocialsg/digital-social-mobile-in-2015), mesmo re-
giões pouco desenvolvidas como a África já têm mais de 25% de sua 
população ativa na internet.
Mesmo com essa evidência de que o software está cada dia mais fa-
zendo parte da vida de todas as pessoas do planeta, ainda tenho a im-
pressão de que não damos a ele a devida atenção e cuidado. Pense em 
todas as vezes em que você usou um software nos últimos sete dias. 
6
Você teve alguma experiência frustrante com ele? Tenho certeza de 
que sim. 
Eu tenho experiências frustrantes com software diariamente. Mes-
mo softwares feitos por quem consideramos experts no assunto de 
desenvolver software – como Google, Facebook e outras empresas 
que nasceram e cresceram fazendo-os e que são frequentemente ci-
tadas como referências do processo do seu desenvolvimento – nos 
causam frustração. 
POR QUE ISSO ACONTECE?
O desenvolvimento de software evoluiu muito ao longo dos anos. Em 
termos de processo, antigamente tínhamos o waterfall, em que cada 
fase do desenvolvimento de software acontecia de forma sequencial. 
A distância entre a necessidade que gerou a demanda de desenvolver 
o software e o software propriamente dito era enorme. 
No início deste milênio, começamos a experimentar as metodologias 
ágeis, que transformaram o processo de desenvolvimento de sof-
tware em um ciclo com interações curtas que promovem o feedback 
contínuo. Isso ajudou consideravelmente a diminuir a distância entre 
a necessidade que gerou a demanda de desenvolver o software e o 
software propriamente dito. 
Do ponto de vista dos aspectos levados em consideração no desen-
volvimento de software, também evoluímos bastante. Os primeiros 
7
softwares eram desenvolvidos por times compostos exclusivamen-
te por desenvolvedores de software. Aliás, não era raro esses times 
serem compostos de uma única pessoa. Cada vez mais vemos times 
multidisciplinares trabalhando juntos no desenvolvimento de softwa-
re; o que é muito bom, pois traz novas visões para o software que está 
sendo desenvolvido. 
De um lado, a preocupação com o usuário, seus objetivos ao usar o 
software e sua interação com esse software são cuidados por profis-
sionais de experiência do usuário, ou UX (do inglês User eXperience).
Do outro lado, a preocupação com a operação do software – ou seja, 
onde esse software vai rodar e que performance e disponibilidade ele 
precisa ter – trouxe profissionais de administração de sistemas, os Sy-
sAdmins (do inglês System Administrators), mais próximos do processo 
de desenvolvimento de software. Essa aproximação da operação do 
software com o seu desenvolvimento é o que deu origem ao termo e 
à cultura DevOps.
Ou seja, entregamos software mais frequentemente, e trouxemos UX 
e SysAdmins para o desenvolvimento de software; mas será que isso 
é suficiente? Como vamos contar para o mundo, ou melhor, para as 
pessoas que podem ser beneficiadas com esse software, que esse 
software existe? Como vamos cuidar das suas questões jurídicas? 
Quando o usuário tiver um problema com o software, como vamos 
ajudá-lo? Como vamos gerenciar o retorno que ele trará? Como ga-
rantir que esse software atenda os objetivos de seu dono ao mesmo 
tempo em que atenda a necessidade de seus usuários?
8
GESTÃO DE PRODUTOS DE SOFTWARE
Pensando nessas questões, algumas empresas que são consideradas 
experts no tema desenvolvimento de software começaram a adotar uma 
nova função em seu processo de desenvolvimento de software, a Ges-
tão de Produtos de Software. Essa função tem por objetivo garantir 
que um software sendo desenvolvido atenda aos objetivos de seu dono 
ao mesmo tempo em que atenda à necessidade de seus usuários.
Além disso, essa função tem de pensar em todos os aspectos do softwa-
re que citei anteriormente. Algumas metodologias ágeis, como o Scrum, 
têm o papel do Product Owner, que tem como principal responsabili-
dade priorizar os itens a serem desenvolvidos. De uma certa forma, a 
Gestão de Produtos de Software é isso, mas ainda é um pouco mais.
É sobre isso que vou falar neste livro. :-)
PARA QUEM É ESTE LIVRO?
A resposta a essa pergunta é bem simples. Este livro é indicado para 
qualquer pessoa que trabalhe com software. Ele serve para pessoas 
que são gestoras de produto, pois todo gestor de produto sabe que 
sempre há muito por aprender. E mesmo aqueles que já conheçam 
bem todos os temas apresentados aqui poderão tirar proveito revendo 
algum assunto.
Este livro também é indicado para qualquer pessoa que esteja que-
rendo entrar na carreira de gestor de produto. Acredito que ele possa 
9
tirar um pouco da ansiedade de quem estiver pensando em se tornar 
gestor de produto, e não sabe ao certo o que fará e o que as outras 
pessoas esperarão dele. 
Lembro uma vez de um amigo meu que era desenvolvedor de software 
e decidiu virar gestor de produtos. Ele disse que, nos primeiros meses, 
ele não entendia o que estava fazendo. Acostumado a medir o pro-
gresso do seu trabalho com código em produção, ao assumir a gestão 
de produtos, ficou perdido sem entender como medir se ele estava de 
fato entregando algo. Chegou inclusive a pensar em voltar a ser de-
senvolvedor de software. Já vi casos de pessoas que experimentaram 
por dois ou três meses e voltaram à função anterior.
Acredito que mesmo as pessoas que não são e não pretendem ser gesto-
ras de produto também poderão tirar proveito deste livro, entendendo 
o que essa função faz e como ela deve se relacionar com as outras 
áreas.
Note que eu disse que este livro é indicado para qualquer pessoa que 
trabalhe com software. Mesmo empresas que não tem software como 
seu core business utilizam software no seu dia a dia e, não raro, desen-
volveram algum software que tem interface com seus clientes como, 
um site ou um aplicativo mobile, por exemplo. É importante para essas 
empresas entenderem a função de gestão de produtos de software, 
para elas poderem gerir melhor esse software e aumentar suas chan-
ces de sucesso.
Vale lembrar de que este livro não tem a pretensão de cobrir de for-
ma extensiva todos os temas que serão abordados, mesmo porque, se 
10
o fizesse, provavelmente teria de ser em uma coleção de livros. Meu 
objetivo é falar sobre os principais temas relacionados com gestão de 
produtos de software, aprofundando em alguns temas específicos e 
fornecendo várias dicas de leitura adicional.
Em alguns lugares do livro, farei referências sobreas metodologias 
ágeis de desenvolvimento de software e o papel de PO (product owner). 
Acredito que o conhecimento desse processo de desenvolvimento e 
dos diferentes papéis envolvidos nele não seja necessariamente um 
pré-requisito para a leitura deste livro, mas é certamente um saber 
que ajudará a aumentar as chances de sucesso do seu software. Caso 
você queira se aprofundar no tema, recomendo o livro Agile: Desenvol-
vimento de software com entregas frequentes e foco no valor de negócio, 
do André Faria Gomes. Além de explicar os princípios por trás da cul-
tura ágil, ele também fala sobre Scrum, XP e Kanban (as três metodo-
logias ágeis mais conhecidas), e sobre como espalhar essa cultura por 
toda a empresa. Leitura recomendada.
ESTRUTURA DO LIVRO
Escrevi o livro seguindo a seguinte estrutura:
• Definições e requisitos: para começar, farei uma rápida introdução 
às metodologias ágeis. Algumas das pessoas que leram os primeiros 
rascunhos acharam que poderia ser útil fazer esta introdução, já que 
falo sobre seus determinados aspectos em alguns pontos do livro. Em 
seguida, definirei algumas palavras-chave como software, produto, 
plataforma, gestão de produtos, entre outras. Nesta parte, falarei tam-
11
bém sobre as características de um bom gestor de produto, e darei 
algumas dicas para gestores de produto sobre liderança e cultura or-
ganizacional.
• Ciclo de vida de um produto de software: nesta parte, descreve-
rei como é o ciclo de vida de um produto de software e quais são 
as fases deste ciclo: inovação, crescimento, maturidade e fim de vida. 
Ainda, falarei sobre o que é inovação, como encontrar um problema 
a ser resolvido, como descobrir se ele é de fato uma oportunidade a 
ser perseguida e como obter retorno com seu produto de software. 
Na fase do crescimento, quando o produto foi desenvolvido e lança-
do, devemos nos preocupar em como gerenciar o produto durante 
seu crescimento, ou seja, como gerenciar o feedback? O que é um 
roadmap? Como priorizar as demandas? O que fazer com pedidos 
especiais? Como dizer não? Que métricas acompanhar? Após esse 
crescimento, vem a maturidade. Nessa parte, vamos entender quando 
acontece a maturidade e o que fazer se o produto chega nessa fase. 
Depois da maturidade, ou quando o produto é desenvolvido mas não 
dá certo, chega a fase conhecida como fim de vida de um produto de 
software. Veremos como detectar e o que fazer nessa fase do ciclo. No 
final, quando já conhecermos todas as fases do ciclo de vida de um 
produto, mostrarei qual a diferença entre startup e gestão de produtos 
de software.
• Relacionamento com as outras funções: como o gestor de produtos 
deve se relacionar com as diferentes funções da empresa, como enge-
nharia, UX, marketing de produtos, gestão de projetos, vendas, jurídico, 
financeiro e atendimento?
12
• Gestão de portfólio de produtos: por que algumas empresas de-
cidem ter mais de um produto? Como elas fazem para gerenciar esse 
portfólio de produtos? Por que outras empresas preferem se focar em 
um único produto? Foco ou diversificação, qual é a estratégia mais 
apropriada? Como organizar o time de desenvolvimento de produtos 
de acordo com a estratégia escolhida? Esses temas são os quais con-
sidero tópicos avançados de gestão de produtos de software, e é o 
que veremos nos capítulos que compõem esta parte do livro.
• Onde usar gestão de produtos de software: será que gestão de 
produtos de software só pode ser usada por empresas que comercia-
lizam produtos de software e somente nos times de desenvolvimento 
que desenvolvem softwares comercializados como produtos? Ou será 
que outros tipos de empresa se beneficiariam ao pensar em seu sof-
tware como um produto e ao usar as técnicas de gestão de produtos 
para aumentar as chances de sucesso dos softwares que desenvol-
vem? E onde devemos colocar a gestão de produtos de software em 
uma empresa? No marketing? Na área técnica? Esses serão os temas 
dos capítulos finais do livro.
Essa sequência tem uma ordem lógica de assuntos, e alguns capítulos 
referenciam temas abordados em capítulos anteriores. Por esse motivo, 
recomendo a leitura sequencial do livro. Contudo, eles também podem 
ser lidos isoladamente. Se você estiver muito curioso para ler sobre um 
determinado tema, pode pular direto para o respectivo capítulo.
Boa leitura!
13
Quem é esse cara para 
falar sobre gestão de 
produtos de software?
Acho a sua pergunta bastante pertinente e apropriada; por isso, aqui 
vai um pequeno histórico. Acredito que minha experiência com gestão 
de produtos de software vem da época das primeiras linhas de código 
que escrevi, em meados da década de 1980. Desde desses primeiros 
programas, já me preocupava com facilidade de uso. 
Naquela época, elementos de interação como menus, janelas e mouse 
estavam começando a ficar populares com as primeiras versões do 
Microsoft Windows e do Mac OS. Isso me mostrou que software não 
era composto apenas de um conjunto de instruções para a máquina 
executar. Para fazer um bom software, era (e ainda é) preciso pensar 
em como esse software deve interagir com seus usuários, se ele aten-
de os objetivos de quem o desenvolveu, e assim por diante.
No final de 1992, quando estava terminando a faculdade de Engenha-
ria da Computação no ITA, um tio meu me falou que ele conheceu um 
negócio muito bacana de computadores chamado BBS (Bulletin Board 
System). Ele não entendia nada de computadores, mas disse que tinha 
14
algo a ver com redes, e que se eu achasse interessante, nós podíamos 
abrir um negócio juntos. Com mais dois sócios, meu tio e eu criamos 
a Dialdata BBS, que depois viria a ser um dos primeiros provedores de 
acesso à internet do Brasil, em 1995. 
Durante esses anos na Dialdata, escrevi muitas linhas de código que 
se transformaram em softwares, que eram disponibilizados para os 
usuários da BBS usarem. Também escrevi o sistema de cobrança, utili-
zado pelos funcionários da Dialdata, para fazer a cobrança dos clien-
tes. A interação com usuários internos e externos me ensinou muito 
sobre desenvolvimento de software. Não basta só ter uma ideia na 
cabeça e um computador na mão para sair codando o software. É 
preciso entender o que o usuário espera do software, e o que você e 
sua empresa planejam obter com ele.
Em 1998, a Dialdata foi vendida para uma empresa americana chama-
da VIA NET.WORKS, que estava comprando provedores de serviços de 
internet em vários lugares do mundo para criar um provedor global de 
serviços de internet, para fazer um IPO (Initial Public Offering, ou oferta 
pública inicial de ações em uma bolsa de valores). Nessa época, fui 
convidado para trabalhar com gestão de produtos na VIA NET.WORKS. 
Foi a primeira vez em que tive contato com o termo e a função de 
gestão de produtos. Minha responsabilidade era criar um portfólio 
global de produtos a partir das diferentes ofertas de produtos das 
empresas que foram sendo adquiridas pela VIA NET.WORKS. Foi aí 
que comecei a entender a importância desse papel em empresas de 
tecnologia em geral e, especificamente, nas empresas de desenvol-
vimento de software.
15
Em 2005, Gilberto Mautner, que também estudou no ITA, me convidou 
para ajudá-lo a melhorar o processo de desenvolvimento de produtos 
na empresa dele, a Locaweb. Hoje, temos na Locaweb um portfólio de 
mais de 30 produtos e um time de mais de 10 gestores de produtos. O 
time completo de desenvolvimento de produtos – incluindo gestores 
de produto, designers de UX e engenheiros de software – conta com 
mais de 100 pessoas. Aprendemos muito ao longo desses anos, mas o 
processo de aprendizado não acabou e acho que nunca acabará; ele 
é constante e contínuo.
QUAL É O SEU PROPÓSITO?
Recentemente, li um livro intitulado Como Avaliar Sua Vida (How will you 
measure your life?), do Prof. Clayton Christensen,professor de Harvard 
e criador do conceito de inovação disruptiva, que vou comentar mais 
à frente. Nesse livro, publicado em 2012, ele conta como percebeu 
que ao longo dos anos seus colegas de turma acabaram se tornando 
pessoas infelizes, com suas vidas pessoais e profissionais distantes da 
que haviam planejado na época da faculdade. Alguns tinham seus no-
mes atrelados a escândalos financeiros e fiscais. Outros se casaram, 
separaram e brigam judicialmente com os ex-cônjuges. Outros ainda 
mal conseguem acompanhar o crescimento dos filhos. 
Essa constatação o fez refletir sobre como seria possível aumentar as 
chances de encontrar satisfação e felicidade ao longo da vida. No li-
vro, ele propõe que uma forma de se fazer isso é aplicando algumas 
das ferramentas do mundo da administração à gestão da vida pessoal 
e profissional. 
16
Uma dessas ferramentas é o propósito. O propósito empresarial é o 
motivo de existir de uma determinada empresa. Muitas publicam esse 
motivo de forma clara. O Google tem por propósito organizar toda a 
informação do mundo, e fazê-la universalmente acessível e útil. A Nike 
quer trazer inspiração e inovação para todos os atletas do mundo, e 
que se você tem um corpo, você também é um atleta. 
Prof. Christensen propõe que as pessoas também tenham um propósi-
to que deve nortear suas decisões ao longo da vida, da mesma forma 
que as empresas devem ter um propósito que norteie as suas. Achei 
essa ideia bem interessante e me provocou a pensar no meu propósito 
que, após analisar como invisto meu tempo e no que tenho prazer e 
satisfação em trabalhar, acabei definindo como sendo:
ajudar as pessoas a criarem produtos de software melhores.
MEU PROPÓSITO É
18
Prefácio
Meu nome é Paulo Silveira e sou empreendedor há 13 anos. Ajudei 
a criar uma grande comunidade de desenvolvedores, o GUJ.com.br, 
além de três empresas de ensino e tecnologia, dentre elas a prória edi-
tora Casa do Código. Cada ano e mês que passa, tenho mais dificulda-
de em definir o que faço e quais são as minhas responsabilidades no 
trabalho. No término do expediente, muitas vezes tenho dificuldade em 
dizer que fui produtivo. 
Ao ler o livro do Joaquim Torres, pude concluir o que já imaginava: sou 
realmente um gerente de produtos. Um que precisa melhorar muito. 
Como sei disso? Em um dos primeiros capítulos, Torres colocará uma 
lista de tarefas que fazem parte do dia a dia dos gerentes de produtos. 
É um spoiler, mas decidi colocar essa lista logo a seguir, com comen-
tários meus, mostrando como todos são (deveriam ser) relevantes no 
meu cotidiano:
Com quantos clientes e usuários você falou essa semana?
Se você não se sente na pele do seu usuário, certamente não enxerga 
as limitações do produto, e nem consegue priorizar o roadmap de for-
ma criteriosa. Algumas vezes, eu respondo um ticket de um cliente e 
percebo que estou distante das necessidades deles. Esse tête-à-tête é 
19
fundamental e não posso deixar de lado.
Você tem uma estratégia e uma visão de longo prazo para o seu 
produto?
Parece fácil, mas esse exercício exige muito mais do que você imagina. 
Mesmo a visão de 2 anos, considerada um prazo relativamente curto, 
pode te dar dor de cabeça para imaginar. Se eu não sei onde quero 
estar em 2 anos, tenho certeza da motivação do que estou fazendo 
agora? 
Como está e quais as últimas mudanças no cenário competitivo 
de seu produto?
Às vezes, me pego sem visitar os sites das empresas concorrentes 
por um longo tempo. Quando vou visitar, muitas vezes a surpresa é 
amarga. Essa situação pode ser ainda mais complicada no mercado 
de startups, tendo em vista que você pode ter concorrentes não muito 
bem definidos, seja pelo nicho específico, seja pelo mercado ainda 
incipiente.
Que insights você teve sobre o seu produto essa semana?
Certamente eu e meus sócios temos diversas ideias sobre o nosso 
produto, mas, na maioria das vezes, nunca comunicamos uns aos ou-
tros. Mais ainda: eu costumo ser muito crítico logo no início.
Você sabe qual a motivação e a métrica de cada item de seu road-
map?
De que adianta implementar tantas features se você não consegue 
mais dizer o porquê delas existirem? Porém, o mais grave: por que 
investir tanto esforço em uma feature que você não vai conseguir dizer 
20
se agradou o usuário, se ajudou nas vendas, se resolveu um proble-
ma? Acredite: essa situação acontece todos os dias conosco e não 
percebemos.
Que novas tecnologias você vê aparecendo que podem influen-
ciar, ou mesmo competir, com o seu produto?
A disrupção pode ser um pouco mais rara do que a mídia pinta por aí, 
mas ela existe. Mais importante: ela vem lá de baixo, normalmente de 
alguma outra tecnologia ou de outro mercado que você não dá muita 
bola. Fique atento.
Que novas habilidades você está procurando aprender?
Se a sua lista está vazia, você tem um problema! Cuidado para não ser 
absorvido pelo operacional. Claro que remover impeditivos é impor-
tante, como também é abordado no livro, mas o aprendizado deve ser 
contínuo. Bem, você já está no caminho certo ao encarar este livro.
Não é à toa que as perguntas são sempre muito relacionadas ao usu-
ário. Enxergar-se como ele; user centric. Torres também gosta de evitar 
os termos belicosos que aparecem em livros negócios: ele sabe muito 
bem a importância que concorrentes possuem no mercado, e que eles 
têm papel importante no ecossistema. 
No meio de dezenas de referências, livros e dicas, Joaquim Torres não 
vai trazer respostas simples para você. Muito pelo contrário. Assim 
como essa lista de tarefas, o autor nos apresenta perguntas, muitas 
perguntas. Dessa forma, você estará mais preparado para o trabalho.
21
Não mencionei o currículo do Joaquim Torres, mas esse é também um 
dos motivos pelo qual sempre o admirei e o considero como um dos 
meu mentores: foi o criador de uma das mais famosas BBSs, e é diretor 
da maior empresa de hosting do país, por onde passa por diversos 
desafios e amplia a gama de produtos da Locaweb. Essa experiência 
permeia o livro nos diversos exemplos dados. Aproveite!
Por Paulo Silveira
22
23
Sumário
PARTE I — DEFINIÇÕES E REQUISITOS
01 O QUE É UM PRODUTO DE SOFTWARE? 29
02 O QUE É GESTÃO DE PRODUTOS DE SOFTWARE? 39
03 GESTOR DE PRODUTOS OU PRODUCT OWNER? 51
04 PRINCIPAIS CARACTERÍSTICAS DE UM GESTOR 
 DE PRODUTOS 59
05 DICAS DE LIDERANÇA PARA GESTORES DE PRODUTO 67
06 CULTURA ORGANIZACIONAL 75
PARTE II — CICLO DE VIDA DE UM PRODUTO DE
SOFTWARE
07 COMO É O CICLO DE VIDA DE UM PRODUTO DE 
 SOFTWARE? 91
08 INOVAÇÃO: O QUE É INOVAÇÃO? 101
09 INOVAÇÃO: FOCO NO PROBLEMA 107
10 INOVAÇÃO: O TRABALHO A SER FEITO 119
 11 INOVAÇÃO: MUITAS OPORTUNIDADES 125
12 INOVAÇÃO: COMO OBTER RETORNO COM SEU 
 PRODUTO DE SOFTWARE? 133
13 INOVAÇÃO: PRÓXIMOS PASSOS 149
14 CRESCIMENTO: FEEDBACK 157
24
15 CRESCIMENTO: O QUE É UM ROADMAP? 167
16 CRESCIMENTO: COMO PRIORIZAR O ROADMAP? 185
17 CRESCIMENTO: SEJA UM “DATA GEEK” 199
18 CRESCIMENTO: ENGAJAMENTO E CHURN 207
19 CRESCIMENTO: MÉTRICAS FINANCEIRAS 215
20 CRESCIMENTO: A MÉTRICA DA LEALDADE 223
21 CRESCIMENTO: CONSIDERAÇÕES SOBRE MÉTRICAS 231
22 MATURIDADE 241
23 FIM DE VIDA 255
24 QUAL A DIFERENÇA ENTRE STARTUP E GESTÃO 
 DE PRODUTOS? 265
PARTE III — RELACIONAMENTO COM AS OUTRAS 
ÁREAS
25 ENGENHARIA DE PRODUTOS E GESTÃO 
DE PRODUTOS 273
26 UX E GESTÃO DE PRODUTOS 281
27 QUAL A DIFERENÇA ENTRE GESTÃO DE MARKETING 
 DE PRODUTOS E GESTÃO DE PRODUTOS? 297
28 QUAL A DIFERENÇA ENTRE GESTÃO DE PROJETOS 
 E GESTÃO DE PRODUTOS? 305
29 E AS OUTRAS ÁREAS? 313
30 DEFININDO RESPONSABILIDADES 32525
PARTE IV — GESTÃO DE PORTFÓLIO DE 
PRODUTOS
31 JÁ ESTÁ PENSANDO EM SEU NOVO PRODUTO? 
 NÃO? ENTÃO JÁ ESTÁ ATRASADO 333
32 COMO DIVERSIFICAR SEU PORTFÓLIO 
DE PRODUTOS? 341
33 COMO GERIR UM PORTFÓLIO DE PRODUTOS? 349
34 FOCO OU DIVERSIFICAÇÃO? 363
35 ORGANIZANDO PARA O FOCO E PARA A 
 DIVERSIFICAÇÃO 373
PARTE V — ONDE USAR GESTÃO DE PRODUTOS 
DE SOFTWARE
36 QUE TIPO DE EMPRESA PRECISA DE UM GESTOR 
 DE PRODUTOS? 385
37 O PROBLEMA DA TI 393
38 ONDE FICA A GESTÃO DE PRODUTOS DE 
 SOFTWARE EM UMA EMPRESA? 403
39 CONCLUSÃO 411
PARTE I
DEFINIÇÕES E 
REQUISITOS
27
Antes mesmo de definir gestão de produtos de software, 
vamos começar do começo, ou seja, definindo o que é sof-
tware e o que é um produto de software. Em seguida, fala-
rei sobre o que é gestão de produtos de software e quais 
são as principais características para ser um bom gestor. 
Abordarei também as diferenças entre gestor de produtos e 
product owner, e quando é o momento certo para uma em-
presa ter um gestor. Por fim, darei algumas dicas de lideran-
ça para gestores de produtos que têm responsabilidade de 
liderar sem ser “chefe” de ninguém.
Preparado? :-)
28
O QUE É UM PRODUTO 
DE SOFTWARE?
CAPÍTULO 01
30
A ntes mesmo de definir produto de software, acho que seria bom definirmos o que é software. De acordo com a Wikipé-
dia (https://en.wikipedia.org/wiki/Software):
Software é qualquer conjunto de instruções que direciona o processa-
dor de um computador (o hardware) a executar operações específicas.
SOFTWARE
Nesse artigo da Wikipédia, existe até uma comparação do software com 
a música, em que os instrumentos musicais estão para o hardware como 
a música produzida nesses instrumentos está para o software. Achei essa 
comparação interessante.
Ótimo, já temos então uma definição de software, mas o que é 
então um produto de software? 
Você certamente já usou algum produto de software, afinal, a inter-
net é feita de produtos de software. Google, Facebook e Twitter são 
bons exemplos que você certamente já utilizou, e talvez use diariamen-
te. Quando você faz compras na Amazon ou no Submarino, também 
está utilizando um produto de software. O sistema de internet banking 
do seu banco também pode ser considerado um, como o Netflix, que 
você pode acessar do computador, do smartphone, do tablet ou mes-
mo direto de sua TV.
O iOS e o Android, sistemas operacionais de smartphones, são produ-
31
Então, todo software pode ser considerado um produto de software? 
Não, pois existem softwares que não têm usuários. São os softwares 
que fazem interface com outros softwares. Alguns exemplos são:
• Drivers de dispositivos de hardware que fazem a tradução 
entre o dispositivo e as aplicações ou o sistema operacional.
• Firmware, que é aquele conjunto de instruções operacionais progra-
madas diretamente no hardware de um equipamento eletrônico.
• Camada de compatibilidade, que permite softwares rodarem em um 
ambiente no qual não foram originalmente programados para rodar.
Contudo, mesmo esse tipo de software se beneficiaria dos concei-
tos e das práticas da gestão de produtos de software que abordarei 
neste livro.
tos de software. Existem também os produtos de software não online: 
os mais conhecidos, como o Office, Autocad, SAP e outros; e os me-
nos conhecidos, aqueles softwares embarcados, que vêm dentro de 
hardwares que não são nem computadores, nem tablets, nem smar-
tphones, mas sim dentro da impressora, da TV, de consoles de video-
game, da urna eletrônica, de equipamentos de rede como roteadores, 
switches, hubs e firewalls etc.
Um produto de software é qualquer software que tenha usuários.
PRODUTO DE SOFTWARE
32
Podem-se classificar os produtos de software de diferentes formas, 
dependendo de como os enxergamos. Podemos olhar, como descrito 
anteriormente, para a forma como o produto é entregue aos usuários 
(como online, não online e embarcado), ou de acordo com o que ele 
faz: e-mail, comércio eletrônico, pagamento, e-mail marketing, gestão 
de conteúdo, educação, comunicação, colaboração, relatório, entre-
tenimento, sistema operacional, ERP, CRM etc.
Outra forma – que é a qual prefiro, pois coloca o usuário no centro – é 
olhar e classificar produtos entendendo para quem o produto resolve 
o problema. Desse ponto de vista, podemos ter três tipos de produto 
de software:
Para o consumidor final: nesse tipo de produto, resolve-se um pro-
blema para o consumidor final que está disposto a pagar uma taxa 
para usar os serviços. Alguns exemplos são Netflix, LinkedIn e jogos. 
Pode-se também pensar em produtos web para consumidores finais 
que paguem a taxa pelo uso de forma indireta, ou seja, a taxa paga é 
por um serviço maior e o produto web está embutido nesse serviço. 
Alguns exemplos são internet banking, intranet de colégio ou faculda-
de, acesso a resultado de exames laboratoriais e softwares embarca-
dos de forma geral. Os sites de comércio eletrônico são também dessa 
categoria, pois o uso do site é gratuito e a taxa paga é pelos produtos 
comprados no site que são entregues para o usuário.
Tipos de produtos de 
software
33
Para as empresas: esse tipo de produto resolve o problema de empre-
sas, que normalmente têm mais disposição de pagar que o consumidor 
final. Alguns exemplos são os produtos da Locaweb, Google AdWords, 
SAP, Autocad e Microsoft Office.
Mistos: nesse caso, o produto resolve tanto um problema para o con-
sumidor final quanto para as empresas. Normalmente, esse tipo de 
produto não tem nenhum custo para o consumidor final; quem paga 
a conta são as empresas. O modelo mais comum de geração de re-
ceita nesse tipo de produto é o anúncio, pago pela empresa quando 
o consumidor final vê o anúncio, clica nele ou compra algo a partir 
dele. Alguns exemplos são Buscapé, Mercado Livre, Google Search + 
Google AdWords e UOL Conteúdo + anúncios. 
Note que, na descrição de cada um desses tipos, tive a preocupação 
de deixar claro quem paga a conta. Isso é muito importante, pois todo 
produto de software tem custos. Por mais acessíveis que sejam esses 
custos, eles existem; logo, todo produto de software precisa gerar re-
ceita de alguma forma, para que ele cumpra sua missão de resolver o 
problema de um grupo de pessoas.
Mesmo eu preferindo a classificação dos produtos de software enten-
dendo para quem o produto resolve o problema, as outras formas de 
se classificar também são válidas, e não são excludentes. Por exemplo, 
o Netflix é um produto de software para o usuário final, mas também é 
um produto de software online de entretenimento.
34
Produto ou plataforma?
Cada vez mais vemos produtos de software que podem ser classifica-
dos como plataformas. Exemplos não faltam, desde grandes empre-
sas de tecnologia como:
• Google que, com dois produtos (Search e AdWords), criou uma pla-
taforma conectando pessoas que buscam informações na internet 
com pessoas que querem anunciar coisas na internet.
• Facebook, que começou como uma plataforma em que amigos se 
encontravam e trocavam informações, e tornou-se uma plataforma 
onde anunciantes podem falar com pessoas por meio de anúncios e 
páginas de empresas.
• LinkedIn, uma plataforma para profissionais, empresas e, mais re-
centemente, anunciantes.
• Apple, que conecta desenvolvedores de software com usuários de 
iPhone, iPad e Macs com sua AppStore. Outra plataforma da Apple é o 
iTunes, conectando produtores de mídia com pessoas interessadas em 
música, filmes, séries e livros.
• Amazon Kindle, plataforma para que editoras ou autores possam publicar 
livros para pessoas interessadas nesses conteúdos.
Aliás, algumas dessas empresas têm mais de uma plataforma, como 
Google, Apple e Amazon.35
Além dessas grandes empresas de tecnologia, existem também os 
exemplos mais recentes:
• Uber, conectando motoristas com pessoas querendo transporte.
• Airbnb, conectando quem tem imóvel para alugar por períodos curtos 
com quem quer alugar um imóvel nessas condições.
• Bitcoin; quanto mais usuários tiver e quanto mais empresas aceita-
rem Bitcoin, melhor.
• Existem também exemplos de plataformas que não são necessaria-
mente baseadas em tecnologia como os shoppings, que colocam lo-
jas, restaurantes e cinemas próximos às pessoas que querem comprar, 
comer e se divertir.
O QUE SÃO PLATAFORMAS?
Ou seja, são sistemas fortemente baseados no conceito de efeito de 
rede (network effect). Efeito de rede é o valor que os usuários de um 
determinado software obtêm quando outros usuários também utilizam 
o software.
Sistemas que são mais valorizados quanto mais pessoas usam.
PLATAFORMA
36
Existem dois tipos de plataforma:
Plataformas de um único lado (single-side): são aquelas que, quanto 
mais usuários tiver, melhor. Usando um exemplo mais antigo, a máqui-
na de FAX. De nada adianta apenas uma pessoa ter FAX; quanto mais 
pessoas usando, melhor. O mesmo vale para redes sociais (Facebook, 
Twitter etc.).
 Plataformas com múltiplos participantes (cross-side ou multi-side): 
são aquelas em que são necessárias dois ou mais grupos distintos de 
pessoas que fazem uso da plataforma de forma diferente, e que se bene-
ficiam dessa forma diferente de cada grupo usá-las. Esse tipo pode ser 
classificado em 3 categorias:
 a) Plataforma tecnológica: onde a plataforma é o sistema opera-
cional e, de um lado, temos usuários e, do outro, temos desenvolvedo-
res, como: Linux, Windows, AppStore e Android.
37
 b) Plataforma de troca: plataforma que reúne compradores e 
vendedores: MercadoLivre, Uber e Airbnb.
 c) Plataforma de conteúdo: plataforma onde o conteúdo é 
o foco, e a monetização é feita normalmente por meio de anúncios 
(Google, Facebook e portais de notícias).
Veja a seguir um exemplo de plataforma tecnológica com 5 lados:
É importante não confundir o conceito de plataforma no contexto de 
produto, com o conceito de plataforma técnica ou plataforma compu-
tacional. Uma plataforma computacional é qualquer ambiente compu-
tacional onde um software será executado. Já no contexto de produto, 
38
como definimos anteriormente, chamamos o produto de plataforma 
quando existem ganhos para os usuários e quanto mais usuários esti-
verem usando o produto.
Feitas as definições de software, produto de software e plataforma, vamos 
ver agora o que é gestão de produtos de software.
O QUE É GESTÃO DE 
PRODUTOS DE 
SOFTWARE?
CAPÍTULO 02
40
J á temos a definição de produto de software, vimos vários exem-
plos e várias formas de classificar esses produtos. Agora, vamos 
definir a função de gestão de produtos de software:
Gestão de produtos de software é a função responsável por todos os 
aspectos de um produto de software, durante todo o ciclo de vida 
desse produto, desde a sua concepção até o fim de sua vida.
É a função responsável por fazer a conexão entre a estratégia da 
empresa e os problemas e necessidades dos clientes por meio do 
produto de software. Este deve, ao mesmo tempo, ajudar a empresa 
a atingir seus objetivos estratégicos, e solucionar os problemas e as 
necessidades dos clientes.
GESTÃO DE PRODUTOS DE SOFTWARE
Essa definição deixa bem claros três pontos bem importantes:
O primeiro é a responsabilidade por todos os aspectos de um produ-
to de software. Isso significa que um gestor de produtos de software 
deverá se preocupar com a experiência do usuário e com a engenha-
ria de seu produto, incluindo sua arquitetura, infraestrutura e opera-
ção. Também deverá se preocupar com questões legais e financeiras, 
suporte ao cliente, e marketing e venda do produto. 
Preocupar-se não significa fazer todas essas coisas. Na sua empresa, 
existem pessoas e áreas dedicadas a cuidar desses temas. Por isso, 
preocupar-se significa entender esses aspectos, quais são as suas re-
lações com o produto, e como o produto impacta cada uma dessas 
41
áreas. Esse será o tema da Parte III – Relacionamento com as outras áre-
as, onde falarei sobre a relação entre gestão de produtos de software, 
e sobre as outras áreas da empresa.
O segundo ponto é que a responsabilidade ocorre durante todo o ci-
clo de vida do produto. Como vamos ver na Parte II – Ciclo de vida de 
um produto de software, o ciclo de vida de um produto tem diferentes 
fases, e cada uma delas requer atenção especial.
O terceiro ponto é a conexão que a gestão de produtos deve fazer 
entre os objetivos estratégicos da empresa e os problemas e ne-
cessidades dos clientes, que é o que veremos a seguir.
Alinhando estratégia da 
empresa com necessidades de 
clientes
O terceiro ponto bem importante da definição de gestão de produtos 
de software é a responsabilidade por garantir a conexão entre a estra-
tégia da empresa e os problemas e necessidades dos clientes. É na 
interseção entre os objetivos do negócio e a solução dos problemas 
ou necessidade dos clientes que se encontra a gestão de produtos de 
software, como vemos na figura a seguir:
42
Essa é a teoria, e tudo parece simples na teoria. Contudo, como todos 
nós sabemos, na prática a teoria é outra. A gestão de produtos de 
software está bem melhor representada pela figura:
Nessa imagem, vemos Louis Cyr (http://en.wikipedia.org/wiki/Lou-
is_Cyr), considerado em 1890 o homem mais forte do mundo em sua 
época, levantando 227 kg com apenas 3 dedos e 1.967 kg em suas 
costas!
43
Ela representa melhor a gestão de produtos de software, pois nem 
sempre é simples conciliar objetivos da empresa e a solução de um 
problema ou necessidade de clientes. Um exemplo simples é o Fa-
cebook que, como qualquer empresa, precisava de receita para pa-
gar seus custos e dar algum retorno aos seus investidores. Esse era 
o objetivo de negócio do Facebook. Do outro lado, estão os usuários 
do Facebook, que acessam o sistema sem pagar nada e não estavam 
interessados em pagar para acessar. 
O gestor de produtos do Facebook teve de encontrar uma forma de 
obter receita, mas sem cobrar dos usuários. A solução foi encontrar 
um outro tipo de cliente, os anunciantes, dispostos a pagar para exibir 
anúncios para os usuários do site.
ESSA IMAGEM ESTÁ INCOMPLETA
A primeira imagem está incompleta. Ela fala em objetivos estratégicos 
da empresa e em problemas e necessidades dos clientes. Contudo, 
um gestor de produtos não pode olhar apenas para esses dois itens. 
Há um terceiro item muito importante que é a tecnologia disponível. 
O gestor de produtos precisa conhecer a tecnologia disponível para 
saber se é possível resolver o problema ou a necessidade do cliente, 
atendendo aos objetivos estratégicos da empresa. 
Veja a figura a seguir:
44
Core team de desenvolvimento 
de produtos de software
As três preocupações vistas anteriormente nos dão a dica do que 
compõe o sucesso de um produto. Um produto de sucesso deve ser:
• Desejável: resolve problemas ou necessidades de clientes;
• Viável: atende os objetivos estratégicos da empresa; 
• Possível de ser construído: existe tecnologia disponível para 
 desenvolvê-lo. 
45
Esses três quesitos definem as três funções essenciais para se criar 
um produto de sucesso: designer, gestão de produto e desenvolvedor. 
Esse trio é considerado o core team (time principal) para o desenvol-
vimento do produto, e deve estar bem alinhado em todas as fases do 
seu desenvolvimento.
VIÁVEL – O QUE SUSTENTARÁ O 
NEGÓCIO?
O gestor de produto tem duas responsabilidades principais: avaliar as 
oportunidades do produto e definir o produto que será construído. 
Depois de avaliado e decidido que vale a pena desenvolvero produto, 
ele inicia a fase de descobrir exatamente como ele deve ser (junto com 
o core team), incluindo as funcionalidades necessárias, a experiência 
do usuário e os critérios para o lançamento. 
46
DESEJÁVEL – O QUE AS PESSOAS 
PRECISAM?
É aqui que entra a Experiência do Usuário (UX). Há vários papéis em 
um time de UX, porém, o que trabalha em maior colaboração com o 
gestor de produtos é o designer de interação. Ele é responsável por 
buscar um profundo entendimento dos usuários, descobrindo suas 
motivações, comportamentos e habilidades; ajudar na definição dos 
requisitos e, assim, desenhar uma interface que torne a interação do 
usuário com o produto a mais simples e eficiente possível, ao mesmo 
tempo em que atenda aos objetivos do negócio.
POSSIBILIDADE – O QUE PODEMOS 
CONSTRUIR?
O Engenheiro ou Desenvolvedor de Software é o responsável por 
construir o produto efetivamente. Seu papel é importante na fase de 
descoberta do produto para dizer ao seu gestor e ao designer de in-
teração o que é possível ser feito, avaliar o custo das diferentes ideias 
propostas e ajudar a identificar as melhores soluções. É sua responsa-
bilidade definir a tecnologia e arquitetura mais apropriada para desen-
volver um produto de qualidade.
Além disso, está em suas mãos determinar o modelo de negócio que 
deverá ser seguido, e interagir com praticamente todas as outras áreas 
da empresa para definir questões jurídicas, contábeis, financeiras, de 
marketing, de distribuição etc.
47
Com produtos de software, a preocupação é apenas com um único 
tipo de cliente. Em uma plataforma, se ela for single-side, além de 
se preocupar em entender um único tipo de cliente, é preciso en-
tender como ele se relaciona entre si. 
Já se a plataforma for multi-sided, você deve se preocupar com dois 
ou mais tipos diferentes de usuários, e a relação entre usuários de 
mesmo tipo e de tipos diferentes. Ou seja, as preocupações, tanto 
do gestor de produtos como de todas as pessoas que trabalham no 
desenvolvimento da plataforma, podem ser bem mais complexas 
do que em um produto com um único tipo de cliente.
Uma estratégia de plataforma deve mudar as prioridades da em-
presa dona dessa plataforma, uma vez que o cliente não enxerga 
valor unicamente nas funcionalidades do produto que estão 100% 
sob controle da empresa. Além das funcionalidades, o cliente bus-
ca valor nas interações com terceiros, e é responsabilidade da em-
presa (dona da plataforma) gerenciar essas relações, para obter 
os melhores resultados tanto para os participantes da plataforma 
quanto para si mesma.
Qual a diferença entre 
gerenciar um produto ou 
uma plataforma?
48
DUAS NOVAS PREOCUPAÇÕES 
NA GESTÃO DE PLATAFORMAS
Quem gerencia plataformas, além de todas as preocupações de ges-
tão de produtos que descrevo aqui no livro, deve também se preocu-
par com dois novos aspectos:
As funcionalidades dependem da participação dos usuários: em 
inglês, usa-se o termo tipping para essa preocupação, ou seja, como 
fazer a plataforma ganhar usuários para ela poder ser útil para quem 
participa dela? Algumas estratégias para fazer isso são:
 a) Primeiro usuário: conseguir um primeiro usuário que, por si 
só, já atrai outros usuários. Essa é uma tática muito usada por sho-
ppings quando fecham com uma loja de departamentos, que já atrai 
compradores suficientes por si só. Depois, é só falar com outras lojas, 
que certamente terão mais interesse em estar no shopping.
 b) Social: outra forma de conseguir usuários é usar redes e me-
canismos sociais para conquistar mais usuários. Algo como “chame 
seus amigos do Facebook”.
 c) Usuário líder: descobrir qual o perfil do usuário que vai ser 
fortemente atraído pela ideia ao ponto de ser o primeiro a adotar a pla-
taforma. Bitcoin atraiu várias pessoas inicialmente de tecnologia, que 
se apaixonaram pela ideia de um dinheiro não atrelado a um governo, 
e são ferrenhos defensores da ideia.
 d) Benefícios como produto: o próprio produto tem benefícios 
49
suficientes por si só. O Instagram, antes da funcionalidade de compar-
tilhar, era capaz de fazer fotos ficarem legais. O OpenTable, antes da 
funcionalidade de reservas, é um ótimo ERP para restaurantes.
 e) Reduzir preços: é uma estratégia válida para atrair usuários, 
mas vale lembrar que é difícil aumentar o preço depois, principalmen-
te se você reduzir o preço para zero. Claro, você pode subsidiar com 
anúncios, mas você precisa saber se seus usuários vão aceitar anún-
cios e se você vai conseguir anunciantes que queiram pagar.
As funcionalidades dependem de que os usuários se comporta-
rem bem: em inglês, o termo usado para isso é coring, ou seja, como 
garantir que os usuários não vão tirar proveito um do outro, garantindo 
sempre que todos os participantes tenham benefícios? Algumas estra-
tégias para cuidar do coring:
 a) Promova confiança: sites de leilão e de pagamento online 
costumam fazer isso, segurando o dinheiro do comprador até que ele 
diga que recebeu o produto que lhe foi vendido.
 b) Ofereça informação de qualidade: normalmente, aqueles ra-
tings feitos pelos usuários. O grande risco aqui é gerenciar os ratings 
falsos; positivos feitos pela própria pessoa ou empresa que está sendo 
analisada, e negativos pelos concorrentes.
 
 c) Restrinja o uso: torne a associação e o uso mais restrito, o que 
trará sim menos usuários, mas mais usuários de qualidade. É o que fez 
um site chamado eHarmony, de procura de namorado(a). Ele cobra 
uma mensalidade razoavelmente cara (U$ 50.00) e tem um questio-
50
Concluindo
É importante entender se você está trabalhando em um produto ou em 
uma plataforma, pois existem algumas diferenças em gerenciar cada 
um deles.
Uma plataforma precisa de uma estratégia para atrair os primeiros 
usuários, isso é tão ou mais importante do que as funcionalidades. 
Como gestores de um produto de software, temos a tendência em ficar 
animados com funcionalidades técnicas, entretanto, nas plataformas, 
o foco é ainda maior nos usuários, em suas relações e em como atrair 
os primeiros usuários. Além disso, gerir uma plataforma requer con-
trole e governança dos relacionamentos dentro da plataforma, para 
garantir que todos os participantes estejam se beneficiando com ela.
Uma vez que já entendemos o que é a gestão de produtos de software, 
e quais as diferenças entre gerir um software e gerir uma plataforma, 
precisamos agora entender o que é um gestor de produtos de softwa-
re. Esse é o tema do próximo capítulo!
nário bem extenso para ser preenchido. Além disso, mesmo que seu 
algoritmo de matchmaking encontre várias opções, ele só apresentará 
um número limitado para facilitar o processo de escolha.
GESTOR DE PRODUTOS 
OU PRODUCT OWNER?
CAPÍTULO 03
52
G estor de produtos ou product owner? Que termo usar? São papéis diferentes? São complementares? Há sobreposição? 
É melhor ter duas pessoas distintas, uma para cada papel? Ou é me-
lhor combinar os dois papéis em uma única pessoa?
Definições
Antes de mais nada, vamos ver mais um pouco de definições.
O product owner é a pessoa responsável por maximizar o valor do pro-
duto, o trabalho do time de desenvolvimento, e a gestão do backlog do 
produto. Ele é uma pessoa, e não um comitê. 
O product owner pode representar o desejo de um comitê no backlog do 
produto, mas aqueles que quiserem uma alteração nas prioridades dos 
itens de backlog devem convencer o product owner.
Fonte: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
PRODUCT OWNER, SEGUNDO O GUIA DO SCRUM
O product owner representa os stakeholders e é a voz do cliente. Ele é 
responsável por garantir que o time entregue valor para o negócio. 
O product owner escreve (ou faz o time escrever) itens centrados no 
cliente, e classifica e prioriza esses itens, adicionando-osao backlog do 
produto.
Fonte: http://en.wikipedia.org/wiki/Scrum_(software_development)#Product_Owner
PRODUCT OWNER, SEGUNDO A WIKIPÉDIA
53
Pelas definições mostradas, fica claro o foco do product owner em:
• Gerenciar as prioridades do backlog, com base em inputs dos stake-
holders e clientes; e
• Maximizar as entregas do time de desenvolvimento.
 
Por outro lado, no Capítulo 02 – O que é gestão de produtos de softwa-
re?, defini gestão de produtos como sendo:
Gestão de produtos de software é a função responsável por todos os 
aspectos de um produto de software, durante todo o ciclo de vida 
desse produto, desde a sua concepção até o fim de sua vida.
É a função responsável por fazer a conexão entre a estratégia da 
empresa e os problemas e necessidades dos clientes por meio do 
produto de software. Este deve, ao mesmo tempo, ajudar a empresa 
a atingir seus objetivos estratégicos, e solucionar os problemas e as 
necessidades dos clientes.
GESTÃO DE PRODUTOS DE SOFTWARE
Ou seja, o gestor de produtos precisa conhecer bem tanto quem é o 
dono do software e quais os objetivos que este deseja alcançar com 
ele, como quem vai usar esse software e quais os objetivos que esse 
usuário pretende alcançar ao fazer isso. Somente conhecendo os ob-
jetivos tanto do dono do software como de seu usuário é que o gestor 
de produtos poderá definir como será esse software.
54
Dá para perceber que, por um lado, as definições de product owner 
se focam bastante no processo, ou seja, em priorização de backlog e 
em maximização da produção do time de desenvolvimento; enquanto 
a definição de gestão de produto é totalmente focada no resultado, 
ou seja, no software que está sendo feito e nos seus objetivos, tanto 
para o seu dono quanto para seu usuário.
As definições de product owner focam no processo, pois todas as 
metodologias ágeis têm seu foco no processo de desenvolvimento de 
software. O próprio Manifesto Ágil (http://agilemanifesto.org/) diz que 
“Estamos descobrindo maneiras melhores de desenvolver software”. 
Note que a preocupação é em descobrir maneiras melhores de desen-
volvê-lo, e não em descobrir maneiras de desenvolver softwares me-
lhores. É uma diferença sutil do ponto de vista gramatical, mas enorme 
no significado. 
Enquanto “descobrir maneiras melhores de desenvolver software” se 
foca no processo de desenvolver software, quando falamos em “des-
cobrir maneiras de desenvolver softwares melhores”, passamos ime-
diatamente a nos focar no resultado do desenvolvimento de software: 
o software! Por isso, minha definição de gestão de produtos tem foco 
no software e nos objetivos de seu dono e de seus usuários, enquanto 
que as definições de product owner focam em como melhorar o pro-
cesso de desenvolvimento de software.
55
Então são papéis diferentes?
Resposta curta: NÃO. Apesar de terem focos distintos, pode-se dizer 
que são dois lados da mesma moeda. Não dá para ter um sem o outro. 
Ou seja, não dá para focarmos em melhorar o processo de desen-
volvimento de software sem pensarmos em melhorar o software que 
está sendo produzido; da mesma forma que não é possível pensar em 
melhorá-lo sem investir no melhoramento do processo de desenvolvi-
mento de software.
Conversei com pessoas de algumas empresas sobre como eles de-
senharam sua organização de desenvolvimento de software, e vi com 
alguma frequência o uso desses papéis de forma separada, ou seja, 
existem product owners, que são parte do time de desenvolvimento 
de software, e são responsáveis por gerenciar o backlog e detalhar os 
itens desse backlog; e existem os gestores de produto, que não fazem 
parte do time de desenvolvimento, são responsáveis pela visão de ne-
gócio do software e passam para o time grandes épicos que deverão 
ser detalhados por um product owner.
Na Locaweb, optamos por usar os termos gestor de produto e pro-
duct owner como sinônimos, pois, como dito anteriormente, para nós 
são dois lados da mesma moeda. Não dá para priorizar o backlog e 
maximizar as entregas do time de desenvolvimento se você não tiver 
profundo conhecimento dos objetivos do dono e dos usuários desse 
software. Assim como não dá para produzir o melhor software que 
atenda os objetivos tanto do dono como de seus usuários se você não 
priorizar corretamente o backlog e não maximizar as entregas do time 
de desenvolvimento. 
56
Conheço algumas empresas que têm essa separação 
de papéis em pessoas distintas e que, ao lerem que es-
ses papéis devem se executados pela mesma pessoa, 
podem pensar que estão com sobra de gente. :-O
Não estão! Muito provavelmente algum outro papel 
está faltando no seu time de desenvolvimento de pro-
dutos de software. Minha recomendação para esses 
casos:
• Não seja radical: não saia demitindo pessoas achan-
do que há sobreposição de papéis. É preciso um olhar 
Um é o “o quê”, e o outro é o “como” do desenvolvimen-
to de software. Não existe um sem o outro.
Depois de ler que gestor de produtos e product owner 
são dois lados da mesma moeda, caso você esteja em 
uma empresa onde esses papéis estão separados em 
duas pessoas distintas, você pode ficar com a dúvida 
sobre o que fazer nessa situação.
O que fazer se na sua empresa 
tiver gestores de produto e 
product owners?
57
mais cuidadosamente, pois outras funções podem es-
tar faltando na sua organização.
 • Marketing de produtos: provavelmente está faltando 
uma pessoa cuidando do marketing de produto, que 
tem objetivos complementares, mas bem diferentes do 
gestor de produto. No Capítulo 28 – Qual a diferença 
entre gestão de marketing de produtos e gestão de pro-
dutos?, escreverei sobre a diferença entre gestões de 
produtos e gestor de marketing de produtos. 
 
• Analise o que está sendo feito hoje: é provável que 
o seu gestor de produtos, às vezes chamado de gestor 
de negócios, esteja fazendo mais coisas de um gestor 
de marketing de produto. Nesse caso, pode ser inte-
ressante que essa pessoa passe a ser de marketing 
de produtos de fato e deixe as atividades de gestor de 
produto, que está fazendo para o product owner even-
tualmente. Este poderá, assim, assumir a gestão de 
produtos.
 
• Use um próximo produto para experimentar com a 
nova divisão de papéis: outra forma de experimentar 
com essa nova divisão de papéis e responsabilidades é 
usá-la somente num novo produto. Quando você esti-
ver pensando em fazer um novo produto, experimente 
essa nova divisão de papéis e veja como esse produto 
evolui. Se der certo, você pode estender para outros 
produtos existentes.
58
Inglês para “gerente” ou “gestor”, em assuntos relacionados à econo-
mia e administração de empresas, e “treinador”, para esportivos.
Fonte: http://pt.wikipedia.org/wiki/Manager
MANAGER
Então, usar gestor de produtos ou gerente de produtos é indiferente, 
pois ambas as palavras servem de tradução para manager. Aqui no 
livro, usarei sempre gestor por uma razão simples. Na cultura corpora-
tiva brasileira, a palavra gerente costuma denotar alguém que “chefia” 
pessoas, só que o gerente de produtos não é chefe de ninguém. 
Essa função não deve gerenciar pessoas, mas gerenciar coisas. Da 
mesma forma que um gerente de contas e um gerente de projetos não 
deve gerenciar pessoas, mas sim contas e projetos, respectivamente. 
Por esse motivo, prefiro usar a palavra gestor, para tirar qualquer co-
notação de que essa função deva gerenciar pessoas.
Agora que já entendemos um pouco mais o que é um gestor de pro-
dutos de software, vamos conhecer quais são as principais caracterís-
ticas dessa função.
Em inglês, a função é conhecida como product manager e, olhando no 
Wikipédia, vemos a seguinte definição para a palavra manager:
Gestor ou gerente de 
produtos?
PRINCIPAIS 
CARACTERÍSTICAS DE 
UM GESTOR DE 
PRODUTOS
CAPÍTULO 04
60
Empatia éa capacidade que uma pessoa tem de se colocar no lugar 
de outra para compreender os seus anseios, motivações, necessidade 
e problemas. Essa característica é importante para entender os clien-
tes e usuários do produto, saber como estes se relacionam com ele, 
e que problema esperam resolver ou que necessidade querem ver 
atendidas. Isso ajudará o gestor de produtos a entender melhor seu 
usuário para poder, junto com o UX e a engenharia, desenhar o melhor 
produto. 
O que uma pessoa precisa ter para ser um bom gestor de pro-dutos? Existem algumas características bem importantes e 
falarei sobre elas aqui, mas a mais importante de todas é, sem dúvida 
alguma, a empatia.
Fonte: Facebook Start Empathy
(https://www.facebook.com/photo.php?fbid=191811397619249&se-
t=a.105965526203837.7401.100867456713644&type=3&theater)
61
Contudo, a empatia não deve ser usada apenas com o cliente ou usu-
ário. O gestor de produtos deve usá-la também no seu relacionamento 
com todas as áreas da empresa, e deve entender o impacto que seu 
produto tem no trabalho delas. Será que aumentaram os problemas 
jurídicos devido a alguma funcionalidade nova no produto? Qual o 
impacto para a equipe de vendas, suporte, operações, financeiro e 
marketing? Até mesmo em relação ao time do produto, engenheiros e 
analistas de UX, como o produto interfere no trabalho desses profis-
sionais? 
A segunda característica mais importante é a comunicação.
Para poder ter empatia, é necessário que o gestor de produtos se comu-
nique com as pessoas nos mais diferentes cenários: em conversas um 
a um e em pequenos grupos, ou fazendo apresentações para grupos 
pequenos e grandes de pessoas, estes que podem ser internos (dentro 
da empresa) ou externos (em conferências, grupos de usuários etc.). 
Deve também ser bom de comunicação escrita (e-mail, blog, docu-
mentação, chat, redes sociais etc.), e ser capaz de discernir sobre 
qual a forma de comunicação mais apropriada para cada momento, 
público e meio de comunicação; e de se comunicar de forma a ser 
entendido pelos diferentes públicos: técnico e não técnico. Como se 
isso tudo não bastasse, ele também precisa ser capaz de se comunicar 
passando segurança e confiança no que está comunicando; afinal, o 
gestor de produto é o porta-voz do produto. 
Porém, não é só de falar que vive o gestor de produtos. Comunicação 
é uma via de mão dupla, ou seja, o gestor de produto tem de ser muito 
62
bom em saber ouvir e compreender o que os outros estão dizendo, e 
entender os anseios e as necessidades deles; o que tem a ver com a 
primeira característica, a empatia.
A terceira característica mais importante é a gestão do tempo. 
O dia a dia de um gestor de produtos pode se encher rapidamente de 
tarefas, e ele precisa ser capaz de perceber e diferenciar o que é ur-
gente do que é importante, para garantir que terá sempre tempo para 
conhecer mais sobre o cliente e o usuário de seu produto. É muito fácil 
um gestor de produtos ver sua agenda repleta de reuniões, com pes-
soas de diferentes áreas para tratar dos mais diversos assuntos: back-
log do produto, atendimento, comunicação de marketing, problemas 
operacionais, revisão de previsão de crescimento, questões jurídicas, 
cobrança, régua de comunicação etc.
Isso acontece pois o gestor de produto deve cuidar de seu produto por 
inteiro. Para o usuário, não existe engenharia, operações, financeiro, 
jurídico, atendimento e cobrança. Ele enxerga tudo isso como parte do 
produto que você cuida; e você tem sim de se importar com tudo isso. 
Contudo, importar-se não significa que você deva ir a todas essas reu-
niões. Se você fizer isso, poderá tirar o foco do que é mais importante 
para o seu produto. Você, como gestor de produtos, precisa focar seu 
tempo em:
 1) Com quantos clientes e usuários você falou essa semana?
 2) Você tem uma estratégia e uma visão de longo prazo para 
 o seu produto?
 3) Como está e quais as últimas mudanças no cenário 
63
 competitivo de seu produto?
 4) Que insights você teve sobre o seu produto essa semana?
 5) Você sabe qual a motivação e a métrica de cada item de 
 seu roadmap?
 6) Que novas tecnologias você vê aparecendo que podem 
 influenciar, ou mesmo competir, com o seu produto?
 7) Que novas habilidades você está procurando aprender?
As reuniões que mencionei anteriormente são importantes, e aconse-
lho você participar delas quando puder. Apesar disso, você terá muito 
pouco a contribuir para essas reuniões se você não se focar nos 7 
itens que acabei de listar. Procure bloquear um tempo em sua agenda 
para focar nisso, e você verá como sua participação nas reuniões será 
muito mais útil e produtiva.
Além dessas três características (empatia, comunicação e gestão do 
tempo), existem mais quatro que vão ajudar o gestor de produtos a 
fazer seu trabalho melhor:
• Novas tecnologias: o gestor de produtos deve estar antenado sobre 
as novas tecnologias para saber como ela pode impactar o seu produ-
to. Acesso via smartphone, como isso impacta o produto? O usuário 
quer acessar via smartphone? Para fazer o quê? Redes sociais, como 
o produto pode tirar proveito delas? Bancos de dados não relacionais, 
quais os benefícios e as deficiências? Go, a nova linguagem de pro-
gramação do Google, no que ela é melhor do que a linguagem usada 
no produto? E no que ela é pior? Smartwatches, smartglasses, como 
isso impacta o produto? Como o usuário espera interagir com o pro-
duto nessas novas interfaces?
64
• Business skills: o gestor de produtos deve entender como cada área 
da empresa funciona e como o produto afeta essas áreas. Como o 
jurídico funciona? Como o produto impacta o departamento jurídico? 
E como o departamento jurídico impacta o produto? Essas perguntas 
podem ser repetidas para todas as áreas da empresa: suporte, opera-
ções, financeiro, RH, marketing, vendas, engenharia e UX.
• Curiosidade aguçada: o gestor de produto precisa ter a capacidade 
de aprender rápido para poder ter insights e fazer julgamentos sobre 
o produto. Deve ser capaz de aprender tanto o lado soft do produto 
(qual é a motivação de negócio, qual problema do cliente o produto 
resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o 
impacto dessa tecnologia, que métricas podemos obter etc.).
 
• Tema do produto: por fim, mas não menos importante, o gestor de 
produtos precisa conhecer sobre o tema do produto. Se for um pro-
duto médico, o gestor de produto deverá entender um pouco sobre 
medicina. Se for um produto financeiro, deverá conhecer um pouco 
de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos 
(como o Cloud Server) e menos técnicos (como a Loja Virtual). A ne-
cessidade de conhecimento técnico é bem diferente nesses dois pro-
dutos. O gestor de produto do Cloud Server deverá conhecer bem a 
fundo questões técnicas, enquanto o gestor de produto da Loja Virtual 
não precisa ter tanto conhecimento técnico, mas deverá saber bastan-
te sobre questões de venda online.
Dá para perceber que essa lista é um conjunto de características que 
nem todas as pessoas têm. É comum casos de pessoas de outras áre-
as que resolvem experimentar a carreira de gestor de produtos, mas 
65
que, após algum tempo, percebem que não têm todas as característi-
cas necessárias. 
Se você é um gestor de produtos, ou deseja ser um, faça uma autoa-
nálise para ver como você está em cada uma das características e, se 
alguma estiver aquém do desejado, foque em desenvolvê-la. Se você 
é responsável por identificar e contratar gestores de produto, use essa 
lista como guia para saber se o candidato tem as características ne-
cessárias para ter sucesso como gestor de produto.
66
DICAS DE 
LIDERANÇA PARA 
GESTORES DE PRODUTO
CAPÍTULO 05
68
Um gestor de produtos tem a difícil tarefa de liderar a evolução do produto,sem ser “chefe” de ninguém. 
Isto é, ele deve convencer todas as pessoas que trabalham 
com seu produto de que o caminho que ele definiu para o 
produto é o mais adequado. 
Em vários textos sobre gestão de produtos, encontramos que 
o gestor é o CEO do produto. Não gosto muito dessa ana-
logia, pois um CEO, em última instância, tem ao seu dispor 
a liderança direta de todas as pessoas da empresa e pode, 
apesar de na maioria das vezes não ser a forma mais ade-
quada, utilizar a hierarquia para atingir seus objetivos. 
Por outro lado, um gestor de produtos trabalha em uma re-
lação matricial, ou seja, não tem liderança direta de nenhu-
ma das pessoas envolvidas com o produto. Aliás, esse é um 
excelente exercício de liderança e uma qualidade extrema-
mente importante para um gestor: liderar sem ter a “chefia” 
organizacional.
Mesmo que ele trabalhe em uma organização totalmente ho-
rizontal, sem nenhuma hierarquia, ele deverá exercer alguma 
liderança para convencer as pessoas a evoluir o produto na 
direção que visualizou.
Por isso, aqui vão duas dicas de liderança que um gestor de 
produto, ou qualquer líder, deve lembrar para liderar de for-
ma eficiente. 
69
A primeira dica é uma de caráter estratégico. O gestor de produtos tem 
a obrigação de:
Entender, comunicar e explicar o contexto no qual se insere o que está 
sendo trabalhado. 
Ajudar o time a entender onde o produto se insere na estratégia da 
empresa e no mercado. 
Saber como os clientes utilizam o produto e o que estes esperam dele, 
e qual o objetivo do produto para o cliente e para a empresa. 
Compreender como uma determinada funcionalidade (ou seja, um 
novo desenvolvimento que o gestor de produto pede para o time) se 
insere no produto e na estratégia desse produto. 
Essa dica parece simples e óbvia, mas não é incomum encontrar pes-
soas que trabalham sem saber exatamente por que estão fazendo seu 
trabalho. Ajudar as pessoas a verem o impacto do seu trabalho faz com 
que elas entendam por que ele é necessário. 
Experimente levar engenheiros de software em sua próxima conversa 
com cliente. Melhor ainda, leve-os a um teste de usabilidade, para que 
eles possam ver seus usuários utilizando o software que eles desen-
volveram. Isso os ajudará a entender por que o software que eles de-
senvolveram existe, qual problema ele resolve e para quem ele resolve 
esse problema.
Setar o contexto
70
Setar o contexto ajuda muito no engajamento das pessoas que 
estão envolvidas com o produto. Elas vão entender a sua impor-
tância tanto para a empresa – que é dona do produto – quanto 
para os seus usuários. Esse engajamento é importante não só 
no core team do produto como também com todas as pessoas 
envolvidas com ele, como o pessoal de vendas, marketing, jurí-
dico e suporte ao cliente. Todos vão se beneficiar se o gestor de 
produto sempre procurar setar seu contexto e onde o trabalho 
de cada área se insere no seu sucesso.
Na Locaweb, temos alguns sistemas antigos que, como todo 
legado, são bem difíceis de mexer: pouca cobertura de testes, 
linguagens de programação antigas, código feito com práticas 
de 10 anos atrás. Sempre que é preciso mexer no código legado 
é um sofrimento. Estamos já trabalhando há alguns anos para 
minimizar a quantidade de código legado, e essa quantidade tem 
de fato diminuído. Contudo, o negócio não para e, às vezes, a 
única saída é mexer nele. Sempre que aparece uma demanda 
dessas, os desenvolvedores perguntam se não dá para esperar o 
novo sistema que o substituirá. 
No início de 2015, apareceu uma demanda desse tipo, em que 
era necessário mexer nos limites e preços de nossos planos de 
hospedagem para acompanhar as mudanças do mercado, que 
estava mais competitivo. Claro que, inicialmente, houve resistên-
cia dos desenvolvedores em mexer no legado, mas quando mos-
tramos todo o racional por trás das mudanças, eles arregaçaram 
as mangas e “sujaram” as mãos no código antigo. 
71
Remover os impedimentos é fundamental para que as 
pessoas do time possam desenvolver o produto. Isso é 
importante para poder termos aquela gostosa sensa-
ção de progresso, de que estamos fazendo algo, cons-
truindo algo. O artigo What Really Motivates Workers (O 
que motiva os trabalhadores) – disponível em http://
hbr.org/2010/01/the-hbr-list-breakthrough-ideas-
-for-2010 –, da Harvard Business Review, mostra uma 
informação muito importante sobre satisfação no tra-
balho. Fizeram um estudo para encontrar o que aconte-
ce em um excelente dia de trabalho. A resposta estava 
em uma palavra: progresso.
Assim que as mudanças foram implementadas, frequentemente 
contávamos para as pessoas que trabalharam nesse projeto so-
bre os seus resultados positivos. Essa compreensão de por que 
algo é pedido e deve ser feito é fundamental tanto para a motiva-
ção de quem for trabalhar na demanda quanto para a qualidade 
do que será entregue.
Remover impedimentos
72
O conselho no final do artigo resume bem a segunda dica:
Evitar escrupulosamente o que estiver impedindo o progresso, evitar 
alterar objetivos autocraticamente, evitar indecisões, ou segurar recur-
sos. Eventos negativos geralmente têm um efeito maior sobre as emo-
ções, percepções e motivações das pessoas do que os positivos, e 
nada é mais desmotivador do que um revés – o tipo mais proeminente 
de evento nos piores dias dos trabalhadores do conhecimento.
73
Bom, então estão aí duas dicas de liderança para gestores de produ-
tos e para qualquer pessoa que se veja liderando algum projeto:
• Setar o contexto;
• Remover impedimentos.
Tenho as usado ao longo de toda minha vida profissional e tem sido 
muito útil!
Concluindo
74
CULTURA 
ORGANIZACIONAL
CAPÍTULO 06
76
C ultura organizacional é um tema muito importante para gestores de produto; por isso, quero abor-
dar um pouco dele aqui. De uma certa forma, esse assunto 
complementa o capítulo anterior, sobre dicas de liderança 
para gestores de produto.
Cultura organizacional é uma característica de toda em-
presa. Até mesmo dentro de uma empresa existem subcul-
turas, ou seja, cada área ou time dentro de uma empresa 
pode ter uma cultura própria. Por exemplo, a cultura de um 
time comercial tem sempre algumas diferenças da cultura 
do time de engenharia de software. 
Não existe cultura certa ou cultura errada. Empresas dife-
rentes têm culturas diferentes e, mesmo assim, podem ter 
sucesso apesar dessas diferenças. A charge a seguir ilus-
tra a diferença de cultura entre Amazon, Apple, Facebook, 
Google, Microsoft e Oracle. Mesmo com essas diferenças 
culturais, todas são empresas de sucesso.
77
Mas o que é cultura organizacional? Edgar Schein, professor da escola 
de administração de empresas do MIT, foi uma das primeiras pessoas 
a falar sobre cultura organizacional nos anos 1970. Segundo ele, cada 
empresa tinha sua própria personalidade, e sua própria forma de agir 
e reagir às situações; forma esta que é passada de funcionário para 
funcionário desde os fundadores da empresa. A definição de Schein 
para Cultura Organizacional é:
Por Manu Cornet. Fonte: http://www.bonkersworld.net/organizational-charts/.
78
Cultura é um conjunto de premissas que foram aprendidas e compar-
tilhadas por um grupo de pessoas enquanto resolviam problemas de 
adaptação externa e de integração interna. Esse conjunto de premis-
sas funciona bem o suficiente para ser considerado válido e, conse-
quentemente, ser ensinado aos novos membros do grupo como a for-
ma correta de perceber, pensar e sentir em relação a esses problemas.
Fonte: SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010.
CULTURA ORGANIZACIONAL
A cultura vem dos fundadores da empresa. Os fundadores têm sua 
própria cultura e é natural que imprimam essa cultura na organização 
que estão criando. Emfunção disso, é muito comum se pensar que ela 
é algo que emerge em uma organização. 
O fundador traz sua cultura e, ao contratar novas pessoas, busca sem-
pre pessoas com cultura similar à sua. Isso acaba criando uma cultu-
ra comum muito próxima daquela trazida pelo fundador da empresa. 
Esse conceito de cultura emergente dá a impressão de que não se 
pode alterá-la deliberadamente, e que ela se desenvolverá de forma 
orgânica. 
Schein alerta que isso é um engano. Culturas podem e devem ser pla-
nejadas. Por esse motivo, vou compartilhar três valores de cultura or-
ganizacional que tenho visto em algumas empresas e que, a meu ver, 
são essenciais na criação de produtos de software de sucesso.
79
Quando erros acontecem, algumas pessoas têm uma tendência natu-
ral de ter como sua primeira reação procurar quem é o culpado, es-
pecialmente em atividades de grupo. Como se ter alguém para culpar 
fizesse o erro, de alguma forma, menos prejudicial. Isso é um grande 
desperdício de tempo e energia. Deixe-me explicar o porquê.
Não desperdiçar tempo 
buscando culpados
Blame game, por Ron Tandberg.
Ocorreu um erro. Erros acontecem. Este é um fato da vida. Não im-
porta o que você está fazendo – desenvolvendo software, publican-
do código em produção, operando um paciente, cozinhando o jantar, 
construindo uma casa, tocando guitarra, jogando futebol, etc. –, há 
boas chances de que erros venham a acontecer.
80
Quando você gasta tempo tentando descobrir quem foi o responsável 
pelo erro, você vai adiar suas tarefas mais importantes em relação a 
ele:
• Compreender o que aconteceu;
• Descobrir como corrigir;
• Encontrar formas de evitar que isso aconteça novamente.
Quando você gasta tempo tentando descobrir quem foi o responsável 
pelo erro, as pessoas podem, naturalmente, tentar esconder o erro por 
temer as consequências. Será que vou ser demitido? Será que vou ser 
excluído do grupo? Será que vou ser punido? Será que as pessoas vão 
zombar de mim?
Quando as pessoas tentam esconder quem foi o responsável, você 
vai acabar adiando as tarefas mais importantes que listei para tratar o 
erro, pois será mais difícil entender o que aconteceu. As pessoas não 
vão dizer toda a verdade sobre o erro e as circunstâncias em que ele 
aconteceu.
Se no processo de entender o que aconteceu, você descobrir que al-
guém foi responsável pelo erro, lide com ele em particular. O mais pro-
vável é que ele tenha o causado sem intenção de fazer mal. Por isso 
você precisa ajudá-lo a melhorar para que ele não cometa mais esse 
tipo de erro. 
Por outro lado, você tem a responsabilidade de criar um ambiente 
onde é seguro falar sobre erros, para que estes sejam detectados o 
mais rápido possível. Contudo, se você descobrir que o erro foi feito 
com intenção de prejudicar a companhia, algum time ou alguma pes-
81
Guerra
É comum ouvir comparações entre o mundo dos negócios 
e situações de guerra, de combate e de luta. Aliás, a pró-
pria palavra “estratégia”, tão comum nas empresas de hoje 
em dia, vem do mundo militar. Vem da palavra grega strate-
gos, junção das palavras stratos (exército) e agos (líder). Ou 
seja, strategos significa originalmente o líder do exército, o 
general, aquele que define como a tropa deverá agir frente 
às situações. 
Um dos livros que constantemente aparece na lista de mais 
recomendados para administração é A Arte da Guerra, um 
tratado militar escrito durante o século IV a.C. por Sun Tzu, 
general chinês.
Quem me conhece sabe que sou uma pessoa pacífica. 
Odeio brigas. Aliás, se acidentalmente entro em uma, estou 
disposto até a pagar para sair. Por isso, sempre que vejo 
essas comparações do mundo de negócios com guerra, 
combate, luta ou competição, me sinto profundamente in-
comodado. Veja a seguir algumas imagens para relembrar 
o que costuma acontecer durante uma guerra:
soa, nesse caso você deve ser direto na repreensão, dizendo que o 
comportamento é inaceitável e, na reincidência, convidar essa pessoa 
a sair do grupo.
83
Empresa é uma instituição jurídica despersonalizada, carac-
terizada pela atividade econômica organizada, ou unitaria-
mente estruturada, destinada à produção ou circulação de 
bens ou de serviços para o mercado ou à intermediação de-
les no circuito econômico.
Fonte: http://pt.wikipedia.org/wiki/Empresa.
Essa definição deixa claro que a empresa existe para produzir e/ou 
servir. Como pode algo que tem por objetivo produzir e/ou servir, ter 
por analogia algo que tem como objetivo a destruição? A maneira cor-
reta de olhar uma empresa e seus objetivos é pensando em constru-
ção, em relação ganha-ganha, ou seja, onde o cliente, os funcionários, 
os donos da empresa e a sociedade onde a empresa está inserida 
saem ganhando. Sempre que direcionamos energia para derrotar o 
“oponente” (cliente, competidor, funcionário etc.), estaremos desper-
diçando energia que poderia ser usada em algo construtivo.
Ar, comida e lucro
Não raro vemos acionistas, investidores e funcionários de uma empre-
sa 100% focados nos resultados financeiros dela. Quando em período 
de crise, esse foco consegue ir além dos 100%... :-/
EMPRESA
Buscando na Wikipédia, encontramos a seguinte definição para empresa:
84
Gosto bastante dessa comparação. Toda empresa deve ter 
um propósito, e esse propósito não pode ser derrotar os 
inimigos (como explicado anteriormente), nem conseguir a 
maior quantidade de dinheiro possível. O resultado finan-
ceiro deve sempre ser usado como uma das métricas que 
indicam que a empresa está tendo sucesso, que está cum-
prindo com o seu propósito. Contudo, mesmo como métri-
ca, ela não deve ser olhada de forma isolada, pois existe a 
boa e a má receita.
A má receita é toda receita obtida às custas do detrimen-
to do relacionamento com o cliente. Por exemplo, imagi-
ne uma empresa que presta um serviço com pagamento 
mensal; quando um cliente quer cancelar, ela dificulta sua 
saída para manter aquela fonte de receita por mais alguns 
meses. Isso é uma má receita. Quando uma companhia 
aérea cobra uma taxa para adiantar o horário de um voo, 
mesmo sabendo que o avião tem espaço de sobra; isso é 
má receita. As taxas de roaming internacionais exorbitantes 
Certa vez ouvi uma frase, popularizada por Dick Costolo, CEO do Twit-
ter, que comparava receita a oxigênio:
Receita é como oxigênio, é necessário, é vital para a saúde e para o su-
cesso de uma empresa, mas não é propósito da vida. Você não acorda 
de manhã e a primeira coisa que pensa é “como eu posso conseguir 
mais ar?”
85
também são um bom exemplo disso, como locadoras de 
veículos que cobram a taxa de gasolina quando você de-
volve o carro sem estar com o tanque cheio, com preço de 
gasolina bem mais caro que o do mercado. Se uma empre-
sa vende algo com o preço acima do adequado, aprovei-
tando-se do fato de que você precisa daquele item como, 
por exemplo, o custo absurdo da garrafa de água em um 
hotel, isso também é uma má receita.
Ou seja, apesar de a comparação de receita e lucro com 
oxigênio ser boa, ela é incompleta, pois não capta o efeito 
da má receita. Raramente você pensa no oxigênio, a não 
ser que esteja com falta de ar. Eu não acho que a receita só 
deva ser lembrada quando está faltando. Receita é o que 
mantém a empresa viva, capaz de executar seu propósito. 
Se for uma boa receita, a empresa vai continuar cumprindo 
seu propósito por muitos anos. Já se for uma má, ela terá 
dificuldades no médio prazo.
Por esse motivo, prefiro comparar receita e lucro com 
comida. Da mesma forma que as pessoas saudáveis não 
pensam em oxigênio o dia inteiro, pessoas saudáveis tam-
bém não pensam em comida o dia todo. Contudo, diferen-
temente do oxigênio, quando falamos de comida, existe 
a comida boa, saudável, que faz bem para o seu corpo; e 
existe a comida má, que vai prejudicar