Inspirado

Um guia sobre como gerir o desenvolvimento de produtos de tecnologia, com base no que os clientes querem, assinado por Marty Cagan, um dos maiores especialistas no assunto no Vale do Silício  

Ideias centrais: 

1 – O propósito das descobertas de produtos é separar rapidamente as boas ideias das ruins. Isso significa obter respostas a quatro perguntas cruciais: 1. O usuário comprará isso? 2. O usuário consegue entender isso? 3. Nossos engenheiros conseguem desenvolver isso? 4. Nossos stakeholders apoiam e dão meios para isso? 

2 – Todo negócio depende de clientes. E o que os clientes compram – ou escolhem usar – é o seu produto. O produto é o resultado do que o time de produto desenvolve e o gerente de produto é responsável pelo que o time de produto desenvolverá. 

3 – Um dos princípios-chave para uma visão eficaz de produto: comece pelo porquê. Este é coincidentemente o nome de um grande livro de Simon Sinek. A noção central aqui é usar a visão de produto para articular o seu propósito. Tudo resulta disso. 

4 – Cliente de referência é um cliente real (não amigos de família), que está operando seu produto em produção (não um teste ou protótipo) que pagou com dinheiro real pelo produto e está disposto a contar aos outros a excelência de seu produto. 

5 – Boas equipes de produto obtêm inspiração e ideias de produto de sua visão e objetivos, da observação das dificuldades dos clientes, da análise dos dados que clientes geram a partir do uso de produto e da busca constante de novas tecnologias. Equipes ruins coletam exigências de vendas e clientes.  

Sobre o autor: 

Marty Cagan é amplamente reconhecido como o principal líder de ideias de gestão de produtos de tecnologia. É o fundador do Silicon Valley Product Group. Trabalhou para desenvolver produtos de empresas ícones: Hewlett-Packard, Netscape Communications e e-Bay. 

Parte 1 – Lições das principais empresas de tecnologia 

Em meados da década de 1980, eu era um jovem engenheiro de software trabalhando para a Hewlett-Packard em produto de ampla repercussão. Era um tempo (a primeira vez) em que a inteligência artificial era a última moda e fui sortudo o suficiente por trabalhar no que era então uma das melhores empresas de tecnologia do setor, como parte de uma equipe de engenharia de software muito forte (vários membros daquela equipe tiveram um sucesso substancial em empresas no ramo). 

Ao tentar rastrear a causa da falha de um projeto na HP, aprendi que as decisões sobre o que desenvolver vinham de um gerente de produto – alguém que geralmente faz parte da área de marketing e que era responsável por definir os produtos que desenvolvíamos. Mas também aprendi que a HP não era boa no gerenciamento de produtos. Aprendi depois que muitas empresas também não eram boas nisso e, na verdade, muitas ainda não são. 

Escolhi esta carreira porque queria trabalhar com produtos que os clientes amam – produtos que inspiram e oferecem um valor real. Acho que a maioria dos líderes de produtos também querem criar produtos inspiradores e bem-sucedidos. Mas a maioria dos produtos não são inspiradores e a vida é muito curta para produtos ruins. 

Serviços e produtos movidos à tecnologia. Há muitos tipos de produtos por aí, mas neste livro me concentro exclusivamente nos produtos que são movidos à tecnologia. Alguma coisa do que exploramos neste livro pode te ajudar se estiver desenvolvendo produtos não tecnológicos, mas não existem garantias nesse caso. Francamente, já existe uma ampla variedade de informações prontamente acessíveis para produtos não tecnológicos, tais como a maioria dos produtos embalados para consumo e para gerentes destes produtos não tecnológicos. 

Meu foco está nos desafios e problemas únicos associados à construção de produtos, serviços e experiências movidos à tecnologia. 

As melhores equipes de produtos que conheço já avançaram além de como muitas equipes praticam estes métodos – alavancando os princípios centrais de Lean e Agile, mas elevando o nível no que elas estão tentando alcançar e em como elas trabalham. 

Quando analiso estas equipes de produtos, vejo três princípios abrangentes de trabalho: 

1. Riscos são abordados com antecedência, em vez de no fim. Em equipes modernas, nós abordamos estes riscos antes de decidir desenvolver qualquer coisa. Estes riscos incluem risco de valor (se os clientes o comprarão), risco de usabilidade (se os usuários conseguem compreender como usá-lo), risco de viabilidade (se nossos engenheiros conseguem desenvolver o que precisamos com o tempo, habilidades e tecnologia que temos) e risco de viabilidade do negócio (se esta solução também funciona para os vários aspectos do nosso negócio – vendas, marketing, finanças, jurídico, etc.). 
2. Produtos são definidos e projetados colaborativamente, em vez de sequencialmente. Elas finalmente foram além do antigo modelo em que um gerente de produto define requisitos, um designer projeta uma solução que entrega nesses requisitos e então a engenharia implementa esses requisitos, com cada pessoa vivendo com restrições e decisões daqueles que precediam. Em fortes equipes, produtos, design e engenharia trabalham lado a lado, em um modo recíproco, para encontrar soluções movidas à tecnologia que nossos clientes adoram e que funcionam para o nosso negócio. 
3. Finalmente, a questão tem a ver com resolução de problemas, não implementação de funcionalidades. Roadmaps de produtos convencionais tratam apenas a entrega de soluções. Fortes equipes sabem que não é só implementar uma solução. Eles devem garantir que a solução resolva o problema subjacente. É tudo uma questão de resultados de negócio. 

Descoberta de produtos. O propósito da descoberta de produtos é separar rapidamente as boas ideias das ruins. Seu propósito é um backlog do produto validado. Especificamente, isso significa obter respostas para quatro perguntas cruciais: 

• O usuário comprará isso (ou escolherá usar isso)? 
• O usuário consegue entender como se usa isso? 
• Nossos engenheiros conseguem desenvolver isso? 
• Nossos stakeholders dão suporte para isso? 

Protótipos. A descoberta de produtos deve executar uma série de experimentos rápidos e, para fazer estes experimentos rápida e economicamente, usamos protótipos em vez de produtos. Neste ponto, é oportuno dizer que existem vários tipos de protótipos, cada um para situações e riscos diferentes, mas eles todos exigem no mínimo uma ordem de grandeza de menos tempo e esforço do que para desenvolver um produto. 

Parte II – As pessoas certas 

Todo produto começa com as pessoas na equipe multidisciplinar de produto. A maneira como você define as funções e as pessoas que você seleciona para integrar a equipe muito provavelmente se revelará um fator determinante no seu sucesso ou fracasso. 

Composição da equipe. Um típico time de produtos é composto por um gerente de produto, um designer de produto e algo entre 2 até 10 ou 12 engenheiros. 

É claro que, se o produto em que você estiver trabalhando não tiver uma experiência voltada ao usuário – como em relação a um conjunto de APIs programáticos –, você provavelmente não precisará do designer de produto. Mas vários times de produto precisam desta pessoa a bordo e, ao longo deste livro, geralmente assumirei que o seu time também precisa. 

Estrutura hierárquica do time. Uma equipe de produtos não possui relações hierárquicas – ela tem uma estrutura organizacional horizontal intencionalmente. Geralmente, todos em uma equipe de produtos são colaboradores individuais e não existem gerentes de pessoas. 

As pessoas na equipe tipicamente continuam a reportar para seu gerente funcional. Por exemplo, os engenheiros reportam para um gerente de engenharia. Igualmente, o designer geralmente reporta para um head de design e o gerente de produto reporta para um head de produto. Então, não é uma relação hierárquica. 

Gerente de produto. Em determinado nível, as responsabilidades do gerente de produto são muito diretas. Ele ou ela é responsável por avaliar oportunidades e determinar o que é desenvolvido e entregue para os clientes. Nós geralmente descrevemos o que precisamos que seja desenvolvido no backlog do produto. 

Todo negócio depende dos clientes. E o que os clientes compram – ou escolhem usar – é o seu produto. O produto é o resultado do que o time de produto desenvolve e o gerente de produto é responsável pelo que o time de produto desenvolverá. 

Times de produtos. Sei que várias pessoas anseiam por uma receita para estruturar os times de produtos, mas sempre explico para elas que não existe receita. Ao invés disso, existem alguns princípios centrais: 

1. Alinhamento com estratégias de investimento. É notável para mim quantas empresas encontro nas quais os times são simplesmente reflexos de seus investimentos em andamento. Elas têm certos times porque sempre os tiveram. Mas, é claro, precisamos investir no nosso futuro também. Podemos eliminar produtos que não carregam mais seu próprio peso e podemos frequentemente reduzir os investimentos em nossos produtos “mina de ouro” para que possamos investir mais em produtos fontes de faturamento e crescimento. 
2. Minimizar dependências. Uma grande meta é minimizar dependências. Isso ajuda os times a se moverem mais rapidamente e a se sentirem muito mais autônomos. Apesar do fato de que nós nunca poderemos eliminar inteiramente as dependências, podemos trabalhar para reduzi-las e minimizá-las. 
3. Maximizar alavancagem. À medida que as organizações crescem, frequentemente encontramos necessidades comuns e a crescente importância de serviços compartilhados. Fazemos isso pela velocidade e confiabilidade. Não queremos que todo time reinvente a roda. 
4. Visão de produto e estratégia. A visão de produto descreve onde nós como uma empresa estamos tentando chegar e a estratégia de produto descreve os maiores marcos para chegar lá. Várias organizações, grandes e antigas, não mais têm uma estratégia e visão relevantes, mas esta é a chave.  
5. Tamanho da equipe. Este é um princípio muito prático. O tamanho mínimo para uma equipe de produtos é geralmente de dois engenheiros e um gerente de produto e, se a equipe for responsável pela tecnologia voltada ao usuário, então um designer de produtos é necessário também. Menos que isso é considerado abaixo da massa crítica para uma equipe de produtos. 
6. Alinhamento com usuário e cliente. O alinhamento com usuário e cliente tem benefícios muito reais para o produto e para o time. Se, por exemplo, sua empresa fornece um marketplace de dois lados com compradores em um lado e vendedores no outro, existem vantagens reais para que alguns times foquem os compradores e outros nos vendedores. 
7. Alinhamento com negócios. Em empresas maiores, frequentemente temos múltiplas linhas de negócios, mas uma fundação comum para nossos produtos. Se a tecnologia é verdadeiramente independente das áreas de negócio, então nós apenas poderíamos tratá-las essencialmente como empresas diferentes enquanto estruturamos times de produto. Todavia, na sua maior parte esse não é o caso. Temos múltiplas linhas de negócio, mas todas são desenvolvidas em uma fundação comum e frequentemente integrada. 

Parte III – O produto certo 

Agora que temos fortes equipes de produtos, precisamos responder a esta pergunta fundamental: no que nossa equipe de produtos deve trabalhar? 

Um dos temas deste livro é focar o resultado e não entrega. Perceba que os típicos roadmaps de produto são todos sobre entrega. Contudo, bons times devem entregar resultados de negócios. Contudo, os típicos roadmaps são a causa raiz de muito desperdício e esforços fracassados em empresas de produtos. Assim, os roadmaps são problemáticos e é preciso ver alternativas. 

Anteriormente, eu disse que nós precisávamos reconhecer os dois fatores para roadmaps de estilo convencionais. O primeiro é o desejo de trabalhar primeiramente nos itens de maior valor de negócio. 

No modelo que estou descrevendo, é responsabilidade da gestão fornecer os objetivos específicos de negócio que cada equipe de produtos precisa abordar. A diferença é que agora priorizam os resultados de negócio, em vez de ideias de produto. E, sim, é um pouco irônico que às vezes nós precisemos convencer a gestão para focar nos resultados do negócio. O segundo fator é a necessidade ocasional de se comprometer a uma data inflexível. 

Para um time de produto ser empoderado e agir com qualquer significativo grau de autonomia, ele deve ter um profundo entendimento do contexto mais abrangente. Isso começa com uma clara e persuasiva visão de produto e o caminho para alcançar essa visão é a estratégia de produto. 

Estes são alguns princípios-chave para se ter uma visão eficaz de produto: 

• Comece pelo porquê. Este é coincidentemente o nome de um grande livro sobre o valor de produto de Simon Sinek. A noção central aqui é usar a visão de produto para articular o seu propósito. Tudo resulta disso. 
• Não tenha medo de pensar grande na visão. Muito frequentemente, vejo visões de produtos que não são ambiciosos o suficiente, o tipo de coisa de que podemos ter êxito em seis meses ou um ano, mais ou menos, e não consideráveis o suficiente para inspirar alguém. 
• Determine tendências relevantes e significativas. Muitas empresas ignoram tendências importantes por tempo demais. Não é muito difícil identificar as tendências importantes. O que é difícil é ajudar a organização a entender como essas tendências podem ser alavancadas pelos seus produtos para resolver problemas de clientes de diversas formas. 
• Vá para onde as coisas estão caminhando, não para onde elas estavam. Um importante elemento para a visão do produto é a identificação do que está mudando – assim como o que provavelmente não mudará – no período e tempo da visão de produto. Algumas visões de produto são desenfreadamente otimistas e irreais sobre o quão rapidamente as coisas mudarão e outras são excessivamente conservadoras. Este é geralmente o aspecto mais difícil de uma boa visão de produto. 
• Evangelize contínua e incansavelmente. Não existe algo como a comunicação excessiva quando se trata de explicar e vender a visão. Especialmente em organizações maiores, não tem como fugir da necessidade de evangelização quase constante. Antes que a rádio-peão comece a se espalhar, tranquilize as pessoas. 

Parte IV – O processo correto 

Exploramos equipes de produto na Parte Dois e descrevemos como decidir o que cada equipe precisa focar na Parte Três. Na Parte Quatro, explico como equipes de produto fazem seu trabalho. Analisaremos as técnicas, atividades e melhores práticas utilizadas para repetidamente descobrir e entregar produtos bem-sucedidos. 

Muito embora esta parte seja intitulada de “O processo correto”, espero que você logo perceba que o processo correto não é nenhum único processo. Ao contrário, é mais precisamente descrito como uma combinação de técnicas, mindset e cultura. 

Eu, na maior parte, enfatizo técnicas de descoberta, dado que nosso foco está em gerentes de produto e essa é a responsabilidade inicial deles. 

Princípios de descoberta de produto. Falamos sobre como fazemos descoberta de produto, há um conjunto de princípios centrais que direcionam como trabalhamos. Se os entender, saberá não só como trabalhar bem hoje, mas também como facilmente incorporar novas técnicas conforme elas emergirem no futuro. 

1. Sabemos que não podemos contar com nossos clientes (ou nossos executivos ou stakeholders) para nos falar o que desenvolver. 
2. Clientes não sabem o que é possível e, com os produtos de tecnologia, nenhum de nós sabe o que realmente queremos até de fato vermos. Não é que os clientes ou nossos executivos estejam necessariamente errados. É apenas nosso trabalho garantir que a solução que entregamos resolva o problema subjacente. Esse é provavelmente o princípio mais fundamental em todo produto moderno. 
3. O mais importante é estabelecer valor persuasivo. É tudo difícil, mas a parte mais difícil de todas é criar o valor necessário para que os clientes finalmente escolham comprar ou usar. Conseguimos sobreviver por um tempo com problemas de usabilidade ou de desempenho, mas, sem o valor central, nós realmente não temos nada.  
4. Devemos validar nossas ideias com clientes e usuários reais. Uma das armadilhas mais comuns em produto é acreditar que podemos antecipar a real resposta do cliente a nossos produtos. Poderíamos basear isso em pesquisa com clientes ou em nossas próprias experiências, mas, de qualquer maneira, nós sabemos hoje que devemos validar nossas ideias com clientes e usuários reais. 

Canvas de startup. Por décadas, as pessoas criaram densos planos de negócios para tentar detalhar estes tópicos e como eles pretendem abordá-los. Mas várias pessoas, incluindo eu, escreveram sobre as várias razões de esses antigos planos de negócio terem sido frequentemente mais prejudiciais do que reais. 

Um canvas de startup, um primo próximo do canvas de modelo de negócio, e o lean canvas são designados para serem ferramentas leves a fim de expor esses riscos mais cedo e encorajar a equipe a abordá-los com antecedência. 

Eu prefiro o canvas de startup aos planos de negócio fora de moda, mas também tenho observado que várias equipes de startup ainda gastam muito tempo com seus canvas e continuam adiando esse probleminha incômodo de uma solução que as pessoas querem comprar. 

Clientes de referência. Vamos ser claros sobre o que significa ser um cliente de referência: é um cliente real (não amigos de família), que está operando seu produto em produção (não um teste ou protótipo) que pagou com dinheiro real pelo produto (não foi dado para convencê-lo a usar) e, o mais importante, que está disposto a contar aos outros o quanto ele ama o seu produto (voluntária e sinceramente) 

Amo tanto a técnica de programa de descoberta de cliente porque ela é designada para produzir estes clientes de referência. Descobrimos e desenvolvemos um conjunto de clientes de referência em paralelo com a descoberta e desenvolvimento do produto em si. 

Esteja ciente de que esta técnica demanda esforço considerável, fundamentalmente por parte do gerente de produto. Queria que fosse fácil. Mas também direi que, se você seguir esta técnica, considero o melhor indicador antecipativo de sucesso futuro do produto. 

Princípios de protótipos. Existem várias formas de protótipos. A melhor escolha para você depende do risco específico que está sendo abordado e o tipo de produto. Mas todas as formas de protótipos têm certas características e benefícios em comum. Veja a seguir cinco princípios-chave por trás de seu uso. 

1. O propósito abrangente de qualquer forma de protótipo é aprender algo a um custo muito menor em termos de tempo e esforço do que desenvolver um produto. Todas as formas de protótipo devem exigir pelo menos uma ordem de grandeza de menos tempo e esforço como o produto eventual. 
2. Perceba que um dos benefícios principais de qualquer forma de protótipo é forçar você a analisar um problema em um nível substancialmente mais profundo do que se nós conversássemos sobre isso ou anotássemos algo. 
3. Um protótipo é também uma ferramenta poderosa para colaboração em equipe. Membros de uma equipe de produto e parceiros de negócio podem todos experimentar o protótipo para desenvolver um entendimento compartilhado. 
4. Existem vários possíveis níveis diferentes de fidelidade para um protótipo. A fidelidade fundamental se refere ao quão realístico o protótipo parece. Não existe algo semelhante ao nível apropriado de fidelidade. Às vezes, não é preciso que o protótipo pareça realista e outras vezes ele precisa ser muito realista. O princípio é que criamos o nível correto de fidelidade para um propósito pretendido. 
5. O propósito inicial de um protótipo é abordar um ou mais riscos de produtos (valor, usabilidade, praticabilidade ou viabilidade) na descoberta. Todavia, em vários casos o protótipo continua a fornecer um segundo benefício, que é comunicar aos engenheiros e à organização mais ampla o que precisa ser desenvolvido. 

Teste de usabilidade. Temos várias boas técnicas para testar o valor qualitativamente, mas elas todas dependem de o usuário primeiro entender o que seu produto é e como ele funciona. É por isso que um teste de valor é sempre precedido de um teste de usabilidade. 

Durante o teste, verificamos se o usuário pode descobrir como operar nosso produto, mas o mais importante é que, após um teste de usabilidade, o usuário sabe do que se trata o seu produto e como deve ser usado. Somente depois podemos ter uma conversa com o usuário sobre valor (ou falta dele). 

Teste A/B. O padrão de ouro para este tipo de teste é um teste A/B. Adoramos os testes A/B porque o usuário não sabe que versão de produto ele está vendo. Isso rende dados que são muito preditivos, que é o que nós idealmente queremos. 

Tenha em mente que este teste A/B é ligeiramente diferente do teste A/B de otimização. É no teste de otimização que experimentamos com diferentes chamadas para ação do usuário, diferentes tratamentos de cores em um botão e assim por diante. Conceitualmente, eles são o mesmo, mas, na prática, existem algumas diferenças. O teste de otimização fica normalmente na superfície com alterações de baixo risco, que frequentemente testamos em um split test (50:50). No teste A/B de descoberta, geralmente temos um produto atual aparecendo para 99% de nossos usuários  e o protótipo de dados em tempo real aparecendo para 1% de nossos usuários ou menos. 

Sprint de descoberta. Um sprint de descoberta é um time box de uma semana de trabalho de descoberta do produto, designado para abordar um risco ou problema considerável que sua equipe de produtos esteja enfrentando. 

Um sprint de descoberta é definitivamente útil para mais do que apenas transformação. Ele poderia facilmente ser considerado uma técnica de planejamento de descoberta ou uma técnica de prototipagem de descoberta. Mas é mais útil unir todas estas coisas, logo escolho incluí-lo aqui. 

Em qualquer caso, durante esta semana de intenso trabalho de descoberta, você e sua equipe provavelmente explorarão dúzias de diferentes ideias de produto e abordagens, com a meta de resolver algum problema de negócio significativo. Você sempre terminará sua semana validando sua solução potencial com usuários e clientes reais. E, na minha experiência, o resultado é consistentemente de grande aprendizado e insights – do tipo que pode mudar o curso do seu produto ou sua empresa. 

Parte V – A cultura certa 

Nesta parte final, incitarei o seu foco para o que é mais importante para o seu sucesso. Em particular, como uma grande equipe de produto se comporta e como fortes empresas de produtos proporcionam a estas equipes um ambiente onde elas podem prosperar? 

Com um sinal gratificante para o post clássico “Gerente de Produto Bom/Gerente de Produto Ruim” de Ben Horowitz, para aqueles que não tiveram ainda a oportunidade de participar ou observar uma forte equipe de produtos de perto, proporciono a você um vislumbre em algumas das diferenças importantes entre equipes fortes e fracas: 

• Boas equipes têm uma visão de produtos persuasiva que buscam com uma paixão missionária. Equipes ruins são mercenárias. 
• Boas equipes obtêm sua inspiração e ideias de produto de sua visão e objetivos, da observação das dificuldades dos clientes, da análise dos dados que clientes geram a partir do uso do seu produto e da constante busca para aplicar nova tecnologia a fim de resolver problemas reais. Equipes ruins coletam exigências de vendas e clientes. 
• Boas equipes adoram ter discussões de brainstorming com líderes inteligentes da empresa. Equipes ruins ficam ofendidas quando alguém de fora da sua equipe ousa sugerir que elas façam algo. 
• Boas equipes estão constantemente experimentando novas ideias para inovar, mas fazem isso de forma que proteja o faturamento e a marca. Equipes ruins ainda estão esperando a permissão para executar um teste. 
• Boas equipes assumem compromissos de alta integridade após avaliarem a solicitação e garantirem que têm uma solução viável que funcionará para o cliente e para o negócio. Equipes ruins reclamam por ser uma empresa movida a vendas. 
• Boas equipes ficam obcecadas com seus clientes de referência. Equipes ruins ficam obcecadas com seus concorrentes. 
• Penso em cultura de produto junto com duas dimensões. A primeira é se a empresa pode consistentemente inovar para descobrir soluções valiosas para seus clientes. É aqui que entra a descoberta de produtos. 

A segunda é a execução. Não importa o quão ótimas as ideias sejam se você não conseguir entregar uma versão lançável do seu produto para os seus clientes. É aqui que entra a entrega de produtos. 

O que realmente significa uma forte cultura de inovação? 

• Cultura de experimentação – equipes sabem que podem executar testes; alguns terão sucesso e vários fracassarão e isso é aceitável e compreensível. 
• Cultura de empoderamento – indivíduos e equipes se sentem empoderados para testar uma ideia. 
• Cultura de diversidade de habilidades e diversidade de equipe – equipes apreciam que habilidades diferentes e backgrounds contribuam para inovar soluções – especialmente engenharia, design e produto. 

O que significa ter uma forte cultura de execução? 

• Cultura de senso de urgência – pessoas sentem que estão em tempo de guerra e que, se não encontrarem uma forma de se mover rapidamente, coisas ruins podem acontecer. 
• Cultura de empoderamento – equipes sentem como se tivessem as ferramentas, recursos e permissão para fazer o que quer que seja necessário para atender seus compromissos. 
• Cultura de colaboração – embora o empoderamento e a autonomia da equipe sejam importantes, equipes entendem a necessidade ainda maior de trabalharem juntas para realizar vários dos maiores e mais significativos objetivos. 

Posso dizer a você que realmente existem empresas que são muito fortes tanto na execução quanto na inovação consistente. A Amazon é um dos melhores exemplos. Todavia, também é sabido que o ambiente de trabalho na Amazon não é para corações fracos. Descobri que muitas empresas excepcionalmente fortes na execução são lugares muito difíceis de trabalhar. 

Na minha experiência com empresas, somente algumas são fortes tanto na execução quanto na inovação. Várias são boas em execução, mas fracas em inovação; algumas são fortes em inovação e apenas corretas na execução; e um número deprimente de empresa são fracas tanto na execução quanto na inovação, caso de empresas mais antigas, que perderam seu jeito com o produto, mas têm ainda uma marca forte. 

Resenha: Rogério H. Jönck 

Fotos: unsplash e reeprodução

Ficha técnica: 

Título: Inspirado – Como criar produtos de tecnologia que os clientes amam 

Título original: Inspired 

Autor: Marty Sagan 

Primeira edição: Alta Books