Inspired - Resumo em Português - Parte 4.1
Inspired: how to create tech products customers love – Resumo em Português – Parte 4.1
Nesse texto vamos ao resumo em Português da Parte 4 do livro Inspired do Marty Cagan, um dos livros de Produto mais indicados no mercado e que atualmente não tem uma versão traduzida para o Português.
A Parte 4 é bem longa, com 150 páginas de conteúdo, portanto vamos dividi-la em duas para facilitar a sua leitura. Essa parte é a maior e mais robusta do livro, trazendo o conceito de várias técnicas de Produto como, Story Mapping, Customer Reference, dentre outras.
Não está entendendo o que é a Parte 4.1? Então provavelmente você não leu a Parte 1, a Parte 2 ou a Parte 3.
Parte 4.1 – O Processo Certo
Nessa parte o livro fala de como os times de Produto trabalham, aborda técnicas, atividades e melhores práticas. Mas é bom enfatizar que não existe um único processo certo e sim várias combinações de técnicas, mindset e cultura.
Existem dois grandes desafios para times de Produto. Primeiro, descobrir qual solução precisamos criar para o cliente, e isso inclui garantir que existe demanda e que a solução funcione tanto para o cliente quanto para o negócio, aprendendo o mais rápido possível.
Segundo, precisam garantir uma implementação escalável na qual os clientes possam confiar. Sabemos que nunca teremos 100% de confiança, mas você não deveria ter que liberar uma nova versão e rezar.
Nesse aspecto, o propósito do Discovery é garantir que existe alguma evidência de que quando pedirmos algo para os engenheiros construírem, não será uma perda de tempo. Existem diversas técnicas para fazer Discovery que nos ajudam a entender os clientes e usuários, levantando essas evidências, e a maioria delas não exige tempo de desenvolvimento.
Existem alguns princípios que a serem considerados no Discovery:
Não podemos contar com clientes ou executivos para determinar o que devemos construir. Clientes não sabem o que é possível e, quando se trata de tecnologia, não sabemos o que queremos até vermos.
A coisa mais importante é criar valor real para que os clientes escolham comprar ou usar o produto.
Criar uma boa experiência do usuário é tão ou mais difícil que criar de fato o produto.
Funcionalidades, design e tecnologia estão entrelaçados e são interdependentes.
A maioria das nossas ideias não irá funcionar e as que funcionarem vão requerer várias interações. Portanto, precisamos estar abertos para resolver o problema da maneira que for necessária.
Devemos validar nossas ideias com usuários e clientes reais. Uma das maiores armadilhas é acreditarmos que conseguimos antecipar a resposta dos usuários aos nosso produtos com base em pesquisas ou experiências próprias.
Nosso objetivo no Discovery é validar nossas ideias da maneira mais rápida e barata possível.
É preciso validar a viabilidade técnica das ideias durante o Discovery e não depois. Se a primeira vez que os desenvolvedores viram uma ideia for na planning, você falhou.
É preciso validar a viabilidade de negócio das ideias durante o Discovery e não depois. Viabilidade de negócio inclui considerações financeiras, marketing, vendas, jurídicas, novos negócios e executivos.
É tudo sobre aprendizado compartilhado. O time deve aprender junto e todos entendem o contexto e a razão pela qual as coisas são feitas.
Ferramentas de Discovery
Não existe taxonomia perfeita para as técnicas de Discovery, pois diversas técnicas são úteis em diferentes situações. O livro cita várias delas superficialmente e é isso que veremos nesta parte do capítulo, divididas por tipos.
Técnicas de Concepção
São dois os objetivos gerais dessas técnicas, o primeiro é garantir que todo o time esteja na mesma página, devidamente alinhados e com clareza do propósito, entendem o problema e qual o foco de negócio. O segundo é identificar grandes riscos em torno do problema e da solução proposta.
Lembrando que são quatro riscos principais que tentamos mitigar no Discovery:
Os clientes vão comprar ou escolher usar o produto? (risco de valor)
O cliente consegue entender como usar o produto? (risco de usabilidade)
Nós conseguimos construir? (risco de viabilidade técnica)
Essa solução funciona para o nosso negócio? (risco de viabilidade de negócio)
Se o time não acredita que existem grandes riscos ligados a esses elementos, normalmente procedemos direto para o delivery, reconhecendo que existe uma chance do time descobrir que estava errado, mas é preferível do que a alternativa do time se tornar extremamente conservador e testar absolutamente toda hipótese.
Existem várias formas de levantar oportunidades, mas falaremos sobre três. Lembrando que as técnicas não são excludentes, você pode aplicar uma ou todas, a depender do seu cenário.
Essa técnica geralmente é usada para esforços pequenos ou de média complexidade, como, por exemplo, adicionar uma nova feature não crítica.
Essa é uma técnica super simples que consiste em responder 4 perguntas:
Qual objetivo de negócio essa solução pretende melhorar? (Objetivo)
Como você saberá se funcionou? (Resultado chave)
Qual problema isso irá resolver para seus clientes? (Problema do cliente)
Qual tipo de cliente estamos focando? (Mercado alvo)
As respostas para essas quatro perguntas (que poderiam ser mais, a depender da sua empresa e necessidade), devem estar claras para todos os membros do time antes de seguir para o trabalho pesado de Discovery. Buscar as respostas para essas perguntas é trabalho do Product Manager.
Essa técnica geralmente é usada para esforços de média a alta complexidade que tem múltiplos objetivos, como, por exemplo, trabalhar no redesign do sistema
A Carta ao cliente foi baseada em uma técnica da Amazon na qual você trabalha no processo reverso, começando pelo comunicado de imprensa que você deseja que aconteça na entrega da solução ao mercado.
Nessa técnica a Product Manager realmente escreve o comunicado de imprensa pensando em como o produto melhora a vida dos clientes, quais são os benefícios para eles. Essa técnica força que o time olhe mais para os benefícios gerados do que para as features em si, ou seja, que esteja focado em resultados e não em entregas. Depois de escrito, o time avalia o comunicado e se o time não ver real valor a ser entregue, então talvez devemos reconsiderar e repensar o que pretendemos entregar.
A Carta ao Cliente é uma variação dessa técnica, na qual ao invés de escrever um comunicado de imprensa se escreve uma carta da perspectiva de um cliente muito feliz e impressionado com o produto. A carta destinada para o CEO da empresa, descreve como o produto melhorou a vida daquele cliente. Além disso, também existe uma carta do CEO da empresa, destinada para o time de Produto, explicando como o produto ajudou o negócio.
Essa técnica geralmente é usada para entregas de alta complexidade, como no começo de um produto ou novo negócio dentro da empresa.
Essa técnica te ajuda a destacar rapidamente os principais riscos e suposições de um novo produto, entretanto, é comum que os empreendedores e Product Managers gastem muito tempo tentando elaborar canvas perfeitos e não é esse o objetivo, portanto é preciso atenção a isso.
Além disso, muitas pessoas têm a tendência de focar nos riscos com os quais tem mais "afinidade", para os quais estão mais preparados, que geralmente não são os maiores riscos. É importante destacar que o maior risco de qualquer negócio e produto é o risco relacionado a valor (no canvas, relacionado a solução), visto é que muito difícil encontrar uma solução que os clientes escolham comprar ou usar, especialmente se eles já usam outra forma para solucionar o mesmo problema. Você precisa ser substancialmente melhor que a solução atual para fazer valer o trabalho de trocar algo que se conhece por algo novo.
Que tal um pouco de Product Discovery na prática?
Falando em técnicas de Product Discovery, se você quer saber como começar a aplicar o Discovery na prática, assista a PM3 Lives com a Iris Sayuri, Product Manager na Easynvest. Nessa Live ela mostra como eles desenvolvem um Product Discovery com qualidade na Easynvest, uma das maiores corretoras do país e a primeira que se lançou na corrida online no segmento. Assista agora!
Agora que sabemos o que estamos querendo resolver, vamos para as técnicas usadas em determinar como vamos resolver o problema.
Story Mapping (Mapeamento de histórias)
Essa técnica surgiu da frustração com os backlogs tradicionais e sua falta de contexto. O Story Map é um mapa bi-dimensionais no qual são colocadas as maiores ações dos usuários na horizontal, por ordem de execução da esquerda para a direita. E no eixo vertical são colocados os detalhes daquela ação, esclarecendo as atividades a serem tomadas, e ordenando por criticidade, ou seja, os mais essenciais no topo.
Utilizando essa técnica você tem uma visão holística do que está querendo entregar ao cliente e todo o time consegue ver como as coisas se encaixam. Essas histórias podem ser usadas para criar protótipos e validá-los com usuários. O mapa é uma ferramenta facilmente atualizada ao longo do ciclo de vida do produto.
Começando pelo poder e importância de se ter um cliente referência, que é um cliente real (nada de amigos ou família), que está usando seu produto em produção (não em um trial ou protótipo), que pagou pelo produto, e, mais importante, está disposto a dizer para outras pessoas o quanto gosta do seu produto (voluntariamente e sinceramente).
Um cliente referência é a melhor ferramenta de vendas e é capaz de mudar a dinâmica da equipe de Produto com as outras áreas da empresa. Nessa técnica criaremos esses clientes referência, mas não se engane, esta é uma técnica que exige bastante esforço.
Existem 4 variações principais dessa técnica, cujo conceito principal é o mesmo, mas com algumas diferenças, sendo elas, 1) criando produtos para empresas; 2) criando produtos que são plataformas (API's); 3) criando produtos para serem usados pela sua própria empresa e funcionários; 4) criar produtos para o consumidor final.
O conceito principal aqui é que potenciais clientes querem ver que outras empresas ou pessoas, como eles, estão obtendo sucesso com o uso do seu produto.
Para produtos criados para outras empresas, o número ideal é de seis clientes referência, no seu mercado alvo. Caso seu produto tenha como alvo principal mais de um mercado, tenha em mente que são seis clientes referência por mercado.
Encontrar esses clientes referência não será tão simples. Lembre-se, você está buscando por clientes que realmente sentem o problema e que estão praticamente desesperados pela solução. Além disso, esses clientes precisam querer despender tempo com o time de Produto, testando protótipos e ajudando o time a criar um produto que realmente resolva o problema.
O grande benefício dessa técnica é que os clientes recebem um produto que realmente funciona pra eles e o time de Produto tem acesso a clientes e usuários com os quais pode conhecer com profundidade os problemas e encontrar uma solução que realmente funcione para eles.
É importante que esses clientes aceitem comprar o produto depois de pronto e concordem em ser referências publicamente, se o produto funcionar para eles. Também é primordial que esses clientes entendam que você está buscando por um produto genérico e não algo personalizado, apesar de estar bastante comprometido em entregar uma solução que funcione para eles.
Um ponto importante aqui é entender que recrutar essas empresas pode ser difícil, mas se realmente estiver parecendo impossível, talvez você não esteja buscando resolver um problema realmente importante para eles, sendo esse um indicativo de que você não tenha demanda o suficiente.
Os clientes que participarem dessa técnica devem receber o produto final antes do mercado, e é importante que você invista em um relacionamento sólido com elas, afinal elas podem ser um excelente canal de vendas.
No que diz respeito às outras variações que falamos, quando se trata de um produto do tipo plataforma/API's o processo é bem parecido, mas o resultado são aplicações de referência, ao invés de clientes referência.
Quando falamos de produtos para a própria empresa como dashboards, geralmente seguimos o processo escolhendo de 6 a 8 clientes internos referência que sejam influentes e bem respeitados. Claramente eles não são clientes e não vão pagar pelo produto, mas pediremos que eles trabalhem com ao time e divulguem o produto com os colegas.
Quando se trata de um produto para o consumidor final ao invés de focarmos em 6 clientes referência, focamos em um número grande entre 10 e 50. Para esse tipo de produto precisaremos de técnicas de teste complementares, mas ainda sim essa técnica será útil. No que diz a esforços de marketing, um consumidor não é tão afetado por clientes referência como as empresas, mas será afetado por notícias e redes sociais.
Como pode ver, essa técnica exige bastante trabalho e esforço, mas te dá acesso ao seu público alvo.
Com essas técnicas estaremos em busca de gerar os tipos de ideias que realmente têm possibilidade de resolver problemas reais que impactam no negócio.
Essa é uma das habilidades mais poderosas e importantes para Product Managers e uma grande fonte de inspiração para ideias de produto. Existem vários formatos de entrevista, mas Marty traz 4 perguntas que ele sempre tenta responder com elas:
Os clientes são quem nós pensamos que eram?
Eles realmente tem os problemas que pensamos que eles tinham?
Como o cliente resolve esse problema hoje?
O que seria necessário para que eles mudassem de solução?
Além disso, também traz algumas dicas:
Frequência: O mínimo de entrevistas que se deve fazer são de 2 a 3 horas por semana, toda semana.
Propósito: Você não está tentando provar nada nas entrevistas, você está tentando entender e aprender rapidamente.
Recrutando usuários e clientes: Fale com pessoas no seu mercado alvo e peça uma hora do seu tempo.
Local: Se puder, faça as entrevistas no local do cliente. Prefira entrevistas feitas presencialmente.
Preparação: Tenha claro qual problema você acredita que eles têm.
Quem deve estar presente: O Product Manager, a Product Designer e alguém do time de engenharia. Geralmente o Product Designer conduz a entrevista, o Product Manager faz anotações e as desenvolvedoras observam.
Entrevista: Mantenha as coisas informais e naturais, faça perguntas abertas e tente aprender o que eles têm feito hoje e não o que eles "fariam".
Após: Repasse o que foi aprendido ao restante do time.
Teste Concierge
A ideia do teste Concierge é que você passe a fazer o trabalho do cliente para ele, manualmente e pessoalmente. Assim, aprendendo na prática como usuários reais fazem aquela atividade para que você possa entender como providenciar uma solução melhor.
O Poder do Mau Comportamento do Cliente
Nessa alternativa, passamos a permitir e até a encorajar que os clientes usem nosso produto para resolver problemas diferentes do que havíamos planejado. Por exemplo, desde o início do Ebay existe a categoria "Everything Else" na qual você pode comprar e vender qualquer coisa que o Ebay não conseguia prever, e algumas das maiores inovações do produto vieram dessa categoria, do que os clientes queriam fazer.
O Ebay foi criado com o intuito de facilitar a venda de itens eletrônicos e colecionáveis, mas estava sendo usado para compra e venda de arte, ingressos e até carros. Com isso, o Ebay começou a se movimentar em criar um produto que facilitasse a compra e venda desses novos itens.
O principal aqui é que você investigue o comportamento do cliente para entender quais oportunidades você deve levantar desse uso inesperado. Um outro tipo de oportunidade semelhante é em relação aos desenvolvedores e API's, o que essas API's permitem que façamos e como podemos utilizar essas oportunidades dentro da nossa estratégia de produto.
Os principais tipos de Hack Days são os diretos e indiretos. Nos indiretos, as pessoas podem explorar qualquer ideia de produto que eles quiserem, desde que estejam, mesmo que remotamente ligados à missão da empresa. No tipo direto existe um problema específico ou objetivo de negócio determinado e as pessoas trabalham em cima de ideias que possam solucionar o problema.
Essa técnica traz um grande benefício que é facilitar a inclusão de engenheiros na ideação, além de facilitar a cultura de Produto e estimular que os times sejam missionários e não mercenários.
Chegamos na metade da Parte 4! Curtiu?
Aguenta o coração que no próximo texto tem muito mais, incluindo técnicas de prototipação e testes.
Perdeu a Parte 1 (Lições das principais empresas de tecnologia), a Parte 2 (As Pessoas Certas) ou a Parte 3 (O Produto Certo)? Não deixe de ler.
Aula gratuita – O que é um teste de usabilidade?
Você sempre quis saber como são nossas aulas na prática? Com esta aula gratuita do nosso Curso de Product Discovery, você vai aprender os conceitos fundamentais de usabilidade e como analisá-la em seu Produto segundo as avaliações heurísticas (técnicas) e testes de usabilidade. Assista agora essa super aula da Elisa Volpato!
Curso online de Product Discovery!
Estude com a gente no nossocurso online de Product Discovery. Uma oportunidade incrível de aprender como fazer um bom Product Discovery, aprendendo com profissionais de empresas como Nubank, PicPay, Booking.com, Tapps Games entre outras. São mais de 30 horas de conteúdo em vídeo-aulas, artigos cuidadosamente selecionados e 14 instrutores altamente qualificados. Confira a ementa do curso!
Como fazer um Product Discovery remoto
Teresa Torres e sua visão sobre Product Discovery
Você sabe qual é a importância do processo de discovery?
Tipos de análise de dados: quais são e como fazer em Produto
Ferramentas de Analytics: 8 formas gratuitas de aprender a usar
Reverse Trial como estratégia de Product-led Growth
Migração de carreira: como me tornei Product Owner
O formato de expansão PLG (Product-led Growth) está virando tendência para empresas de tecnologia, principalmente pela eficiência e pelo potencial de escala que ele traz.
Não é de hoje que existe um déficit de profissionais qualificados na área de tecnologia da informação, principalmente quando falamos de squads de desenvolvimento de
Lean Inception (LI) é um workshop colaborativo que tem ficado cada vez mais famoso na comunidade ágil e no ecossistema de Produto. Inclusive, eu já