#02 Bloco de Notas — Resenha do Livro Inspired (Martin Cagan)

O Bloco de Notas é uma nova série na programação do Podcast Mulheres de Produto, que tem como proposta compilar ideias e conceitos dos principais livros da área de produto.

Para este segundo episódio da série, fizemos a resenha do livro Inspired: How to Create Tech Products Customers Love escrito por Martin Cagan.

Episódio anterior:

Escute o episódio piloto sobre o livro Escaping the build trap de Melissa Perri.

Ficha do Episódio:

Apresentação: Erica Castro

Edição: Carolina Lavinas

Cursos PM3 apoia esse podcast e dá 10% de desconto pra quem nos ouve, com opção de parcelamento de 6 e 12 vezes com o cupom MDP10! Aproveitem🙂

Recadinhos:

• Ajude a evoluirmos esta série! Responda nossa pesquisa. É rapidinho!
• Nós adoramos receber sugestões e feedbacks! É só mandar mensagem para podcastmdp@gmail.com.
• Siga a gente no Instagram e no Linkedin!
• Assine a Newsletter!
• Faça parte da comunidade Mulheres de Produto no Slack!

E até o próximo episódio ❤

Transcrição / Adaptação do Áudio:

Oi! Eu sou a Erica e este é o Bloco de Notas, uma série sobre livros da área de Produtos.

Aqui, vamos compilar ideias e conceitos das principais publicações da área.

No episódio anterior fizemos a resenha do livro da Melissa Perri, o Escaping the Build Trap — Como uma gestão de produtos efetiva pode criar valor.

Para o episódio de hoje, escolhemos um livro que também é queridinho das produteiras e produteiros: Inspired: Como criar produtos digitais que os usuários amam, do autor Martin Cagan.

Vou deixar na descrição do episodio o link do livro na Amazon para quem tiver interesse em aprofundar os conceitos. Recomendo! E depois convido que você dê uma passada nas nossas redes sociais para contar o que achou do episódio e, caso tenha lido o livro, que outros aspectos te chamou a atenção. Vamos compartilhar conhecimento!

Bom, para começar, vamos dar aquela passada no índice para ver como livro está estruturado? Ele foi dividido em 5 partes:

Parte 1 — As lições das maiores empresas de tecnologia

Parte 2 — As pessoas certas

Parte 3 — O produto certo

Parte 4 — O processo certo

Parte 5 — A cultura certa

Vem comigo para aprofundar em cada uma das partes desta edição.

Parte 1 — As lições das maiores empresas de tecnologia

No mundo da tecnologia, em geral, as empresas se encontram em alguns destes 3 estágios:

• startups
• em crescimento
• enterprise

E em cada um destes estágios, as empresas se deparam com diferentes desafios:

No estágio de startup, elas precisam validar se o produto é viável e desejável pelo mercado. Como, normalmente , não tem muito investimento inicial, tempo pode determinar a diferença entre o sucesso ou morte do empreendimento. Um fator de sucesso aqui é desenvolver um bom discovery, tema bastante abordado no livro.

Aí, uma vez que o modelo de negócio se confirmou, a empresa entra em um novo estágio, o de crescimento. O desafio é crescer e escalar de forma eficiente. Aqui, as decisões iniciais de utilizar uma infraestrutura mais simples, criada para testar o modelo, começa a ser um desafio e o termo débito técnico começa com frequência nas conversas. Outro desafio é manter todos os times alinhados com as metas da empresa e entendendo seu papel para contribuição desta meta.

Para quem venceu a etapa de escalar o produto, chegou o estágio enterprise. Aqui o desafio é inovar e continuar entregando valor para os clientes e usuários. A dificuldade é que, após ter atingindo com maestria seu objetivo inicial, não está muito evidente qual seria o próximo grande objetivo para o qual a companhia deve dirigir seus esforços. Falta de visão e de autonomia costumam ser reclamações frequentes. E as empresas costumam responder com a criação de comitês para tomada de decisão e centros de inovação, iniciativas que em geral, não são eficientes.

A ideia do Martin é trazer no livro casos de como grandes empresas como amazon, google e netflix conseguiram evitar esse destino.

Então ele faz a provocação. Quais são as causas que fazem tantas inciativas de produto fracassarem? E levanta os 10 maiores problemas.

Como vocês vão observar, muito relacionados a cultura de desenvolvimento de produtos em cascata << vale colocar uma mini definicao >>

Só cuidado para não cair na armadilha de ter carinha de ágil e cabeça de cascata!

• Origem das ideias — em geral, vêm de cima para baixo. Além de não ser a melhor fonte das ideias, tira bastante a autonomia do time, que se tornam tiradores de pedidos.
• Business Cases — com exceção de grandes investimentos, fazer BC para priorizar roadmaps, segundo o autor, é uma piada. Business case deve responder quanto de investimento será necessário e quanto de retorno o produto trará. Mas a verdade é que neste estágio, é impossível saber.
• Roadmaps de Produto — aqui ele traz 2 verdades inconvenientes:

— a maioria das ideias não vão funcionar

— para uma ideia alcançar todo o seu potencial, precisa de muitas iterações

(quem aqui já parou no famoso mvp e já partiu para a próxima feature?)

• o papel da gerente de produto neste modelo — é de um compilar requisitos e documentações para o time. como martin diz: isso é oposto do que é a função de gerente de produto.
• o papel do UX — entram tarde no processo e acabam não aportando o valor de design.
• engenheiros — costumam entrar no processo muito tarde, praticamente para criar código. essas pessoas são ótimas fontes de inovação e não fazem parte do processo deste o início.
• da mesma forma, a agilidade também chega tarde, em geral, na fase de entrega. Isso seria apenas 20% do potencial.
• projeto — no final, todo o processo é focado em projeto, logo olha para entregas e não para resultados.
• processo cascata — onde a validação com o usuário ocorre muito tarde
• custo de oportunidade — ao escolher uma iniciativa de produto, deixamos de priorizar outra.

No final, estamos falando de uma mentalidade de cascata, onde todo o ciclo que vai da ideia a entrega é muito longo e o feedback do usuário chega muito tarde. E podemos ter investido em iniciativas que não resolviam de fato a necessidade o usuário.

Depois de alertar sobre o que não fazer, Martin entra na seara do Lean e Agile mas já alerta: Não existe bala de prata. Como qualquer ferramenta, você precisa ser astuta para usá-las. Mas pela sua experiência, a maioria dos times que tiveram melhores resultados, usaram alguns princípios do lean e da agilidade. Para ele, essas metodologias carregam 3 princípios:

1. riscos são tomados para decidir o que construir -

• risco de valor: os usuários vão comprar
• risco de usabilidade: os usuários vão saber usar?
• risco de viabilidade: é possível desenvolver, considerando tempo, habilidades do time e tecnologia disponível?
• risco de negócio: essa solução funciona para todos os aspectos do negócio (de vendas a jurídico)?

2. produtos devem ser desenvolvidos colaborativamente e não sequencialmente — os melhores times trabalham com produto, design e engenharia trabalhando lado a lado em caminho de via dupla.

3. é sobre resolver problema e não implementar features. Essa é a armadilha que a Melissa Perri tanto bate na tecla no seu livro Escaping the Buid Trap, que tem resenha aqui na série. Depois dá um confere na nossa playlist.

Bom, já que o Martin Cagan colocou os pingos nos is, ele aproveita e também compartilha seu entendimento sobre Produto. Segue a visão: 😉

Segundo o autor, pensar um produto de forma ampla é considerar:

• que ele deve ter algumas funcionalidades
• que precisa de tecnologia para suportar essas funcionalidades
• que inclui experiência do usuário
• que monetiza estas funcionalidades
• que atraia e capture usuários e clientes
• que também inclua uma experiência offline que é essencial para entrega de valor

Novamente, Martin volta a falar sobre a necessidade de rodar o processo de discovery e de delivery continuamente, contrapondo ao modelo de cascata comentando anteriormente. Isso significa que vc tem a engenharia atuando em atividades de discovery, assim como tem gerentes de produtos e designers ajudando no delivery, tirando dúvidas por exemplo.

E falando especificamente sobre o Product Discovery, ele destaca que o propósito desta etapa é separar rapidamente as boas ideias das ruins. O resultado do discovery é validar o backlog do produto. E para rodar um discovery você precisa de experimentos rápidos! E para isso, podemos contar com o apoio de protótipos. A ideia é aprender rápido e de forma barata.

Martin comenta que bons times costumam rodar de 10 a 20 ideias por semana!

E aí vc tem a etapa do Delivery cujo propósito o é construir e entregar algo que seja possível vender e fazer o negócio girar.

Outro conceito que ele traz é da visão de Produto, que é o objetivo do produto num período de mais ou menos 2 a 10 anos. O produto sendo a forma da que a empresa encontrou como entregar a visão da companhia.

Nesta seção, um último conceito que ele traz é do famoso MVP que aportuguesando é o mínimo produto viável. Para Martin, é um dos conceitos mais importantes no mundo de produto e que mesmo assim gera muita confusão nos times de produto.

Martin defende que o MVP nunca deveria ser o produto. Ele deveria ser um protótipo que possibilitasse aprendizagem em dias e até mesmo em horas!

Devo dizer que nessa parte buguei um pouco… e estou ansiosa para ver como ele vai desenrolar essa questão ao longo do livro.

Parte 2: As pessoas certas

Abrindo a segunda parte do livro, Martin já manda a real: como você define as funções e seleciona as pessoas para o time é um fator determinante para o sucesso ou falha do produto. Então o trabalho que ele, Martin, costuma fazer nas empresas é otimizar a efetividade do time de produto.

Na sua definição, não se trata de ser uma squad. Um time de produto é um grupo de pessoas que juntas e com diferentes especialidades sentem e possuem senso de dono sobre o produto.

Martin cita John Doerr, que famoso investidor do Vale do Silício e autor do livro Métricas que importam, que em breve queremos trazer para o Bloco de Notas. Doerr diz:

“Precisamos de missionários, não de mercenários.”

Ai Martin explica: mercenários constroem o que falaram para eles construírem. Já os missionários são fieis a visão e comprometidos para resolver problemas para seus usuários.

Nesta parte do livro ele comenta sobre várias outras características que contribuem para a criação de times fortes:

• empoderar e conceder autonomia para os times
• criar sendo de responsabilidade e comprometimento com os resultados
• fomentar um ambiente de colaboração
• manter os times com um tamanho suficiente para que essa integração não se perca — aqui ele comenta a regra das 2 pizzas.
• com a mesma preocupação, manter a estabilidade nos times, sem tantas trocas entre as squads
• estruturar os times de forma que tenham uma unidade: seja por jornada, tipo de cliente, dispositivo e até arquitetura.
• sobre hierarquia, lembrar que o PM não é chefe de ninguém.

E por que isso funciona?

• Porque para colaborar, você precisa construir e nutrir relacionamentos.
• Para inovar, você precisa de conhecimento especializado e isso consegue com o tempo trabalhando juntos em um contexto
• E em vez de apenas construir o que outros pedem, o time precisa entender dos objetivos de negócio e sentir responsabilidade e senso de dono pelos resultados.

Então se na sua empresa os times não estão dedicados, talvez isso deva ser a 1a coisa a se corrigir.

Fica a dica do tio Martin😉

Ainda sobre times, Martin abre um capítulo só para falar sobre o papel de Gerente de Produto.

Ele já começa destacando 3 formas que a PM / Gerente de Produto pode trabalhar:

1. sendo uma gestora de backlog que escala toda decisão para cima — um chapeu que ele entende ser de um Product Owner, papel existente na metodologia scrum
2. sendo uma gestora de roadmaps, onde toda decisão precisa ser compartilhada com os stakeholders
3. sendo dona do seu trabalho! e para isso, essa pessoa precisa ser o talento mais forte da empresa!

Mais a frente ele pontua como ser essa pessoa, mas antes ele destaca as principais responsabilidades de uma PM: avaliar oportunidades e determinar o que deve ser desenvolvido e entregue aos usuários.

Então, para ser uma PM bem-sucedida, você precisa ter estas 4 saberes:

• profundo conhecimento do usuário: quais são suas questões, dores, desejos, como pensam… e para o negócio, como eles trabalham e como decidem comprar. Sem conhecimento, vc está apenas adivinhando!
• profundo conhecimento sobre dados: parte de conhecer o cliente é saber como ele usa o seu produto. Para se ter uma ideia da importância, ele diz que PMs devem olhar diariamente, de 30 min a 1h, para ferramentas de análises para entender o que se passou nas últimas 24 horas. Dados de vendas, uso, testes A/B etc. E mesmo que vc tenha um analista de dados, você não pode delegar a análise e entendimento do seu usuário!
• profundo conhecimento do negócio: é crítico entender o negócio e como ele funciona e qual o papel do seu produto no negócio. E isso leva a entender e demonstrar para os stakeholders que você conhece cada uma de suas restrições e que está comprometido a entregar soluções que sejam consistentes com estas restrições.
• profundo conhecimento do mercado e da indústria: conhecer os concorrentes , tecnologias emergentes, comportamento e expectativas dos usuários, acompanhar os especialistas do setor e por aí vai.

E por fim, se você quer ter sucesso, não tenha medo de liderar😉

Parte 3 — O Produto certo

Uma vez que você já tem o dream team, agora é hora de definir em que vão trabalhar.

Martin já começa a terceira parte do livro rechaçando os roadmaps tradicionais. Segundo o autor, embora tenha as melhoras intenções, roadmaps de produtos em geral levam a resultados de negócio pífios.

Isso ocorre porque:

1. a maioria das ideias não vão funcionar
2. e mesmo que se provem corretas, elas precisam de várias iterações para que entreguem o valor esperado.

E antes de partir para as alternativas, resgata o objetivo de se utilizar roadmaps:

• a liderança deseja garantir que os times estão trabalhando nas questões mais importantes para o negócio
• podem existir situações que a empresa se comprometeu com datas e o roadmap acaba sendo uma forma de acompanhar o progresso destas entregas

Como o que se espera é garantir resultado e não entrega de features, o que deve ser feito é:

• empoderar o time de produto,
• dar contexto do negócio,
• alinhar sobre a visão que a empresa deseja alcançar,
• priorizar os objetivos de negócios
• definir como o resultado vai ser medido.

Uma vez que essas decisões sejam tomadas, o time de produtos vai trabalhar na melhor forma de alcançar estes objetivos e o resultado chave vai ser a forma de comunicar o avanço com a liderança e a empresa.

De novo, é sobre resultado e não entrega de feature.

Para criar esse alinhamento com a empresa e com os times de produto, é essencial ter bem definidos a visão e estratégia de produto.

A visão de produto é o futuro que se quer criar nos próximos 2 a 5 anos. É a chave para motivar e e inspirar os times.

Já a estratégia de produto é a sequencia de entregas que planejamos executar para concretizar a visão. Uma boa estratégia tem 5 princípios em comum:

• foque em um mercado ou persona por vez — não tente agradar a todos em uma única entrega.
• garanta que a estratégia de produto esteja alinhada com a estratégia de negócios — uma mudança de modelo de negócio por exemplo, impacta no produto e por isso precisam caminhar juntas.
• da mesma forma, também deve estar alinhada com a estratégia de vendas e go to market — se vc tem um novo canal de vendas, precisa garantir que a estratégia de produto está alinhada com este novo canal.
• seja obsessiva com os consumidores não com a concorrência — não quer dizer que vc deve ignorar o mercado, mas o foco deve estar nos clientes.
• comunique a estratégia para toda a empresa, como um evangelista. Todos precisam saber no que estamos focado agora e o que está planejado para depois.

Ainda sobre o Produto certo, Martin dedica um capítulo para falar de OKR, ou Objetivos e Resultados Chave, um sistema de definição de metas usado pelo Google e por diversas empresas de tecnologia. Tem o propósito de trazer foco e alinhamento para a organização, fazendo com que todos andem na mesma direção.

E o que faz um bom OKR?

• Um bom objetivo deve ser qualitativo.
• Já o resultado deve ser mensurável e em termos de resultado de negócio.
• É necessário encontrar uma cadência. Para os times, costuma-se definir por quarter.
• Não tenha muitos objetivos por time. De um a 3 objetivos é aceitável. Da mesma forma, cada resultado chave pode ter de 1 a 3.
• É crítico um acompanhamento do progresso (semanal)
• Se o objetivo falhou é importante ter uma retrospectiva
• Mantenha transparência para a organização sobre quais objetivos cada time está trabalhando e o progresso atual.

Um exemplo de objetivo pode ser: criar uma experiência de cliente incrível

Como key results:

• melhorar o nps de X para Y
• aumentar a taxa de recompra de X para Y

Algo que costuma ocorrer é que cada área acaba criando seus ORKs e isso pode criar conflito com as metas do time de produto. Se isto acontecer, é importante deixar explícito que a prioridade são as metas do time de produto. Qualquer atividade (débito técnico, automação, design responsivo) que não esteja relacionada a estas metas devem ser discutidas e priorizadas, para serem então incorporadas nos objetivos do time de produto.

Martin finaliza a terceira parte do livro fazendo um chamado para as PMs: seja uma evangelista!

Alguém que consegue comunicar o valor que estão entregando, que consegue vender o sonho.

E encerra com 10 conselhos:

1. use protótipos para tangibilizar a ideia
2. compartilhe as dores dos usuários — sempre tenha alguém do time nas visitas e entrevistas com o cliente.
3. compartilhe a visão — tenha a visão, estratégia e princípios de produto muito evidentes e comunique como seu trabalho contribui para esses objetivos
4. compartilhe aprendizado
5. compartilhe créditos — o produto é do time tb
6. aprenda a fazer uma ótima demonstração
7. faça seu trabalho de casa — conheça seu mercado e clientes. você deve ser especialista, incluindo concorrência e tendências
8. seja genuinamente apaixonada pelo que faz
9. aprenda a demonstrar entusiasmo — isso é contagioso
10. passe tempo com o seu time — eles precisam ver seu entusiamos. passe algum tempo com cada uma das pessoas do time. isso impacta na motivação e no resultado do time.

Parte 4: O processo certo

O processo certo é uma combinação de técnicas, mentalidade e cultura.

O foco primário da gestão de produtos deve ser descobrir soluções que os usuários vão amar e que atendam os objetivos de negocio.

Por isso, aprender rápido e entregar com confiança é essencial.

E como podemos ter essa confiança? Por meio de um processo do processo de discovery.

O Discovery deve endereçar os seguintes riscos:

• Risco de Valor: nossos clientes vão comprar isso?
• Risco de usabilidade: nossos clientes vão saber usar?
• Risco de viabilidade: podemos construir isso?
• Risco de viabilidade do negócio: essa solução funciona para nosso negocio?

Responder a estas questões não são uma questão de opinião da PM. Precisamos coletar evidencias.

Martin compartilha 10 princípios que direcionam a mentalidade para realizar um bom discovery:

1. Sabemos que não podemos contar com os clientes e stakeholders para nos dizer o que construir. Clientes não sabem o que é possível construir. Vale lembrar que historicamente, a maioria das inovações, os clientes não tinham a menor ideia, mas eles agora amam.
2. É importante estabelecer valor central para o produto. Porque usuários podem viver por um tempo com alguns problemas de usabilidade mas sem o valor central, não temos produto.
3. Uma boa experiência do usuário é critica para o sucesso.
4. Funcionalidade, design e tecnologia são interconectados. Logo, PM, UX e devs precisam estar lado a lado.
5. É esperado que muitas das ideias não funcionem e outras vão precisar de inúmeras iterações
6. Precisamos validar nossas ideias com usuários e clientes reais.
7. O objetivo do discovery é validar nossas ideias de forma rápida, barata e de forma possível.
8. Precisamos validar a viabilidade das nossas ideias durante o discovery, não depois;
9. Da mesma forma, é necessário validar a viabilidade de negócio durante o discovery também.
10. E por último… é tudo sobre aprendizado compartilhado. Times de missionários aprendem juntos.

Martin diz que se o time não sente que há um risco significativo (financeiro, de negócio, legal e etc), tudo bem seguir para o delivery. Mas mesmo assim, há a possibilidade de estarem errados.

Quando usar o discovery e as técnicas de validação? Para as situações em que há um risco significativo ou quando os membros do time não chegam num consenso.

Martin cita as suas 3 técnicas favoritas de enquadramento:

1. avaliação de oportunidade — indicado para um otimitização de uma feature até um projeto de médio porte

A ideia é responder 4 questões sobre o trabalho de discovery:

• Objetivo: Estamos endereçando qual objetivo de negócio?
• Resultados Chave: Como saberei que tive sucesso?
• Problema do Usuário: Qual problema estamos resolvendo para nossos usuários?
• Mercado alvo: Que tipo de clientes estamos focando?

Nesta ponto, Martin chama a atenção que vários produtos falham porque tentam agradar a todos.

Precisamos identificar o usuário primário que será beneficiado.

Pode ser um tipo de usuário, uma persona, um job to be done.

2. carta a consumidor — para projetos maiores ou iniciativas que possuem múltiplos objetivos ou resultados complexos. Ex disso poderia ser o redesign de uma tela onde se deseja melhorar a experiência do usuário e gerar mais conversão para a empresa.

Martin cita processo da Amazon que faz como se fosse um realease para a imprensa anunciando o lançamento do novo produto e seus benefícios para o cliente. Só que o produto ainda não existe, apenas a ideia dele. É uma forma de criar declarar um problema e criar uma narrativa de como o produto pode resolver esse problema, além de compartilhar a visão com a empresa, pegar feedbacks e evoluir a visão inicial.

Uma variação deste modelo seria uma carta fictícia escrita por um usuário do produto e enviada para o CEO da empresa, onde o usuário está feliz e impressionado com o produto e explica como o novo produto mudou ou melhorou sua vida. Na visão do Martin, é um ótimo exercício de empatia e motivação para o time, pois enfatiza como o trabalho deles pode ajudar a vida dos usuários.

3. canvas startup — quando você está criando algo totalmente novo: uma linha de produtos ou novo negócio.

Se assemelha ao canvas modelo de negócio.

É uma forma rápida de destacar as principais premissas e riscos do novo produto ou negócio.

Além de dar ao time uma visão holística do produto e das principais áreas que afetam o negócio.

Independentemente da técnica de enquadramento, é sempre importante focar no problema em vez da solução. É a famosa frase: “Não se apaixone pela solução, mas sim pelo problema”.

Bom, uma vez que se enquadrou o trabalho do discovery, agora é a hora que ele entrar nas técnicas de planejamento do Discovery. Martin destaca 2 técnicas: Story map e o Programa de descoberta do usuário

1. Story map

Conceito introduzido por Jeff Patton, onde se introduz o contexto às histórias de usuário.

Patton escreveu um livro sobre o assunto e se vc quiser que a gente traga a resenha para o Bloco de Notas, deixa nos comentários.

Bom, o mapa tem 2 dimensões:

Na horizontal, da esquerda para direita são listadas uma dúzia das principais atividades do usuário, em geral, na ordem que a atividade para fazer algo acontece

Na vertical, temos um detalhamento progressivo das atividades. É como se dividíssemos as atividades principais em tarefas menores. Quanto mais em cima, mais críticas são. As que ficam mais embaixo, são opcionais. E com essa estrutura já consegue se delimitar versões, releases de acordo com cada objetivo.

Um bom uso do story map é aplicar as ideias nos protótipos e pegar feedbacks com os usuários. A partir da interação, é possível adicionar novas histórias. Uma vez o discovery finalizado, as historias saem do mapa entram no backlog do produto.

2. Programa de descoberta do usuário

O nosso trabalho em empresas de produto é criar soluções que sustentem o negócio. Não se engane, tudo depende de produtos fortes.

E numa empresa de produto, não há nada mais forte do que usuários referência: um cliente real, que usa seu produto em produção, paga por ele e está disposto a contar ao mundo de forma voluntaria e sincera quanto ama seu produto.

Essa é a melhor ferramenta de vendas e marketing que você pode ter.

E a razão para que o Martin ame esta técnica é que ela é desenhada para criar clientes referência.

O Programa de descoberta do usuário é indicado para grandes iniciativas, pois exigem bastante esforço. Algo como criar novos produtos, negócios ou mercados ou até redesenhar todo um produto.

Em iniciativas B2B, Martin recomenda selecionar 6 potenciais clientes e trabalhar com eles inicialmente. O ideal é procurar clientes que estão passando pela dor e desesperados pela solução que se busca construir. Certamente, se eles encontrarem uma solução que funcione para a realidade deles, muito provavelmente vão comprar.

Como PM, você não deve colocar em features o que os seis estão pedindo. Seu trabalho é mergulhar nos clientes e descobrir uma solução única que funcione bem para os seis.

Você vai interagir com eles, compartilhar os protótipos, testar com seus usuários, fazer perguntas detalhadas. Entregue para este produto as novas versões antes.

Ideação

Martin chama a atenção que a maioria dos times de produto não fazem muitas atividades de ideação. E isso é um problema: em geral não temos a qualidade das ideias que estamos procurando.

Como geramos ideias que realmente vão nos ajudar a resolver problemas de negócio?

Martin apresenta algumas:

• Entrevistas com usuários — existem vários formatos. Independentemente da escolha, em cada interação com o usuário temos a oportunidade de aprender:
• seus clientes são realmente quem vc pensa que eles são?
• eles tem mesmo os problemas que vc imagina que eles tenham?
• como eles resolvem este problema hoje?
• o que poderia substituir a forma como eles fazem hoje?

Concierge — fazer manualmente algo para o cliente de forma a entender a necessidade do cliente

• exige que vc vá até o usuário e peça para ele mostrar como faz hoje
• assim você pode aprender sobre a necessidade dele e entregar uma solução muito melhor

Hack days — uma forma rápida de levantar uma variedade de ideias que solucionem algum problema, seja de negócio ou do cliente, gerando protótipos que podem ser avaliados e testados.

• é uma ótima forma de incluir desenvolvedores no desenho da solução, o que costuma trazer bastante inovação.
• além de fortalecer a cultura de missionários

Prototipação

• O propósito da prototipação é aprender rápido e barato, de forma a reduzir riscos e custos
• É uma forma de pensar em um problema de forma profunda e expor questões que de outra forma, você não teria visibilidade
• É uma poderosa ferramenta de colaboração e compreensão
• Em muitos casos é a própria especificação.

Existem várias formas de protótipos e a escolha depende do risco que está se avaliando.

Se é de viabilidade, por exemplo, pode-se fazer uma poc para avaliar se é possível seguir por um caminho ou tecnologia.

Se está se desenhando uma nova experiência, é necessário colocar o usuário para experimentar, simular o uso.

Testes

• Teste de usabilidade — Queremos saber se o usuário realmente tem o problema que a gente pensa que ele tem.

Fique atenta aos sinais:

• o usuário conseguiu completar a tarefa?
• em algum momento teve dificuldade?
• ficou frustrado e desistiu?

No livro, Martin explora outras orientações super úteis durante os testes de usabilidade. Recomendo a leitura😉

• Teste de valor — Às vezes não temos certeza se teremos demanda para o que vamos construir.

Uma alternativa é criar uma “porta falsa” para mensurar demanda. Pode ser uma leanding page para adquirir um produto ou um botão falso para uma determinada funcionalidade

Ao testar, lembre-se de que não é sobre provar nada. É sobre aprender rápido.

Esta é a mentalidade correta.

E como PM você deve participar de todo teste qualitativo.

• Teste quantitativo — Enquanto testes qualitativos servem para aprender rápido e ter grandes ideias, testes quantitativos são sobre coletar evidências.
• Teste A/B -
• Apenas Convite — você convida usuários para experimentar a nova versão
• Teste de viabilidade — Em vez de perguntar ao time: “Você pode fazer isso” diga, “Qual é a melhor forma de fazer isso e quanto tempo vai levar?”

Mudança cultural

Nem sempre é fácil mudar para uma cultura de orientado à roadmap para orientado a resultado.

Existem algumas técnicas que ajudar nessa mudança de mentalidade e cultura.

Martin cita o Discovery Sprint como um bom processo para ajudar nesta mudança:

Trabalho de uma semana para rastrear um problema ou risco que o time está enfrentando.

É baseado na metodologia do google para resolver problemas e testar novas ideias em 5 dias.

Parte 5: A cultura certa

Martin enquadra cultura em duas dimensões:

• a primeira dimensão é sobre a forma que as empresas conseguem constantemente inovar para gerar soluções que tenham valor para seus clientes. Discovery é sobre isso,
• a segunda é sobre execução. Não importa suas grandes ideias se você não pode produtizá-las e entregá-las aos seus clientes. Delivery é sobre isso.

Você precisa das duas dimensões rolando em paralelo para ter uma cultura de inovação e execução fortes.

Para inovar, você precisa:

• experimentar e saber que algumas coisas vão falhar
• ter mente aberta, porque boas ideias vem de todos os lugares
• empoderar pessoas e times para tentarem novas abordagens
• ser inspirador por novas tecnologia
• ter experts que conheçam do cliente, dos usuários, do negócio
• fomentar diversidade, com pessoas com habilidades e histórias diferentes que contribuam com novos pontos de vista
• processos e técnicas de discovery que testem ideias de forma rapida e segura;
• para conseguir executar bem, você precisa:
• senso se urgência — saber que se não se mover rápido, você pode perder o timing
• de muito comprometimento
• de empoderar os times e garantir que eles tenham os recursos necessários
• de responsabilidade pelos resultados
• colaboração para alcançar juntos os objetivos
• cultura de resultados e não de entrega de features
• reconhecimento

Depois dessa super lista, Martin revela: “Nem todas as empresas conseguem ser fortes nas duas dimensões”. Algumas são ótimas para inovar, outras mandam muito bem na execução. E tem até as que são ruins nas duas dimensões e ainda sobrevivem graças à marca e base de clientes.

E encerra, se quiser uma bom exemplo de quem inova e executa lindamente? Amazon.

E para vocês? Quais são as empresas que continuam mandando bem nos dois quesitos? Tem alguma brazuca para indicar? Conta aqui nos comentários. Vamos adorar saber e estudar esses cases!

Esta foi a resenha do livro Inspired de Martin Cagan! Vamos ficando por aqui, e já pensando no próximo episódio do Bloco de Notas. Alguma ideia de qual livro vamos abordar? Hummm?