10 Razões para um Desenvolvimento de Produto Bem-Sucedido
Há exatamente um ano, fui convidado para a Craft Conference em Budapeste, onde falei sobre as 10 principais razões pelas quais equipes de produto fracassam. Na época, falei principalmente sobre por que muitas equipes são tão ineficazes e, apesar de todas as afirmações em contrário, a maioria das organizações ainda não é realmente "ágil", pois ainda trabalha segundo o princípio da cascata. Por isso, este ano fui novamente convidado para a conferência para falar sobre como trabalham as melhores equipes que conheço. Este artigo é um resumo da minha palestra.
Após minha primeira palestra, algumas pessoas entraram em contato comigo pedindo mais informações. Além de aconselhá-las a ler meu livro ou participar de um workshop , não senti que conseguia dar uma resposta satisfatória. Isso me inspirou a pensar mais detalhadamente sobre as principais características de equipes de produto extremamente fortes . Então elaborei meu top 10 pessoal.
Descoberta e Entrega Contínuas
Assim como descrevi os dez maiores problemas com o modelo Waterfall, também descrevi as dez características de equipes bem-sucedidas em relação a Continuous Discovery e Delivery (também chamado de Dual Track Agile, Discovery Sprints ou Delivery Sprints). Então, quais são os fatores de sucesso para um desenvolvimento de produto bem-sucedido?
1. Equipes de Produto Empoderadas
O fator mais importante é o conceito absolutamente fundamental de equipes de produto fortes. Mas o que isso significa exatamente?
Primeiro, é importante que a equipe exista nessa formação a longo prazo e que os membros da equipe não sejam movidos como peças de xadrez. Se as equipes devem ser inovadoras, precisam de tempo para aprender mais sobre si mesmas, a tecnologia, os clientes e o contexto de negócios.
Segundo, a química entre os membros da equipe também é decisiva. Isso significa que devem se conhecer bem o suficiente e também se respeitar, para que cada membro se sinta confortável o bastante para ousar propor coisas e motivar a si mesmo e aos outros a alcançar melhores resultados constantemente.
Terceiro, uma equipe deve ter uma certa diversidade de habilidades, que normalmente consiste em gestão de produto, design de experiência do usuário e desenvolvimento. Frequentemente, análise de dados e pesquisa de usuários também fazem parte.
E por último, é vantajoso quando todos os membros da equipe trabalham juntos no mesmo local – mesmo que isso não seja um tema simples para muitas empresas. Gerentes de produto, designers de produto e desenvolvedores (ou pelo menos o líder da equipe de desenvolvimento) deveriam ter suas mesas lado a lado. Infelizmente, isso nem sempre é viável, mas pelo menos pode-se tentar. E só para deixar claro, não são equipes individuais em diferentes locais que representam um problema. O que tem impacto negativo na Velocity e, principalmente, na inovação é quando os membros da mesma equipe estão geograficamente separados uns dos outros.
2. Visão e estratégia do produto
Para ter equipes de produto verdadeiramente empoderadas e autônomas, os membros da equipe precisam ter uma boa compreensão do contexto de negócio. Isso começa com uma visão de produto clara e convincente e o caminho até lá: a estratégia de produto.
A visão de produto descreve o mundo que queremos criar nos próximos dois a cinco anos (em hardware geralmente um pouco mais).
A visão de produto precisa ser inspiradora. Uma boa visão de produto é uma das nossas ferramentas de recrutamento mais eficazes e motiva as pessoas a virem trabalhar todos os dias. Uma visão inspiradora atrai bons profissionais, porque eles querem fazer parte de algo significativo.
A estratégia de produto é a sequência de produtos que queremos entregar no caminho para realizar a visão. Seria uma estratégia ruim querer satisfazer todos os envolvidos com um único Release. Em vez disso, temos uma lista priorizada de mercados, geografias ou personas e nos concentramos em fazer o produto e o respectivo mercado se encaixarem.
Quanto mais equipes de produto você tem, mais importante é ter uma visão e estratégia unificadas, para que cada equipe individual possa tomar as decisões certas.
O mais importante, porém, é que a visão de produto seja inspiradora e que a estratégia de produto seja tomada de forma consciente.
3. Resultado de Negócio
A segunda parte do contexto de negócio que uma equipe empoderada e autônoma precisa para tomar boas decisões é um conjunto de objetivos de negócio priorizados. O sistema OKR (Objectives and Key Results) foi criado exatamente para isso.
Os OKRs refletem uma lista de problemas de negócio específicos que a equipe deve resolver. No entanto, estes não são features. Features são apenas potenciais soluções para problemas. Concluir uma feature não torna uma equipe bem-sucedida; resolver o problema real é o que importa.
Os dois princípios por trás desses métodos de gestão de desempenho são:
1) Equipes têm melhor desempenho quando recebem problemas para resolver por conta própria, em vez de receber soluções prontas.
2) A equipe é medida por resultados, não por output. Entregar features de um roadmap é output; resolver um problema de negócio é um resultado.
4. Um competente gerente de produto
Infelizmente, a maioria dos desenvolvedores nunca teve a oportunidade de trabalhar com um gerente de produto competente. Aqueles que tiveram essa experiência são justamente os que insistem em sempre ter uma pessoa assim na equipe. E pior ainda é o fato de que muitos desenvolvedores nem sabem exatamente o que o gerente de produto deveria contribuir para a equipe.
Pense nisso da seguinte forma: para que uma equipe de produto resolva problemas reais de negócio, não basta que a solução funcione tecnicamente ou que o cliente ache a solução incrível. A solução também precisa funcionar para o seu negócio – e isso é frequentemente a parte mais difícil.
Pense no que isso significa. Imagine que você trabalha para a Uber ou AirBnB e precisa lidar com leis complexas, associações de empregadores e sindicatos. Ou pense no eBay, que enfrentou restrições consideráveis para ser classificado como marketplace em vez de site de e-commerce. Ou na Tesla, que precisou esclarecer questões de responsabilidade relacionadas ao piloto automático. Cada empresa tem sua própria lista de obstáculos a superar:
Obstáculos legais, financeiros, relacionados a vendas e preços, marca e marketing, privacidade de dados, segurança, condições de parceria, etc.
Infelizmente, a única pessoa que entende tudo isso é o diretor executivo, e nesse caso dá para compreender por que ele tem tanta dificuldade em empoderar a equipe para tomar as decisões certas por conta própria.
Existem três formas de uma equipe trabalhar. Uma é o diretor executivo ou outro superior decidir tudo. A segunda é o gerente de produto convocar uma grande reunião e discutir tudo com toda a diretoria ("Design By Committee"), o que geralmente produz resultados ruins. A terceira possibilidade é o gerente de produto fazer seu trabalho, lidar com os obstáculos e repassá-los aos membros da equipe para que eles possam desenvolver a solução para o problema por conta própria.
Combine isso com uma boa compreensão da tecnologia e conhecimento sólido sobre usuários e clientes, e você pode perceber por que esse é um trabalho difícil, mas absolutamente essencial para uma equipe de produto, especialmente quando a equipe deve desfrutar de um nível significativo de autonomia.
5. Soluções através da colaboração
"Colaboração" não deve ser apenas uma palavra da moda aqui. Quero dizer simplesmente que as três áreas – produto, design e desenvolvimento – devem trabalhar juntas para resolver um problema, em vez de o gerente de produto passar "requisitos", o designer empacotar tudo de forma bonita e os desenvolvedores escreverem o código que lhes é exigido. A razão para isso é o fato de que, em boas soluções, tecnologia e funcionalidade impulsionam uma à outra. A tecnologia torna certas opções de design possíveis, assim como o design influencia a escolha da tecnologia. E as decisões de design influenciam a funcionalidade – e vice-versa.
Tecnologia, design de experiência do usuário e funcionalidade estão entrelaçados. Boas soluções surgem de um constante ir e vir, um permanente dar e receber entre as três áreas.
Essa também é a principal razão pela qual equipes que trabalham juntas no mesmo local são, em essência, sempre melhores do que equipes em que isso não acontece.
6. Product Discovery: Aprendizado Rápido
Produtos excelentes têm muito a ver com a capacidade de uma equipe de testar rapidamente muitas ideias. Queremos separar as boas das más ideias o mais rápido possível. Product Discovery abrange toda uma série de técnicas que nos ajudam a descobrir rapidamente quais ideias são ótimas e quais nem tanto. Algumas ideias são realmente excelentes e outras nem tanto. Algumas são arriscadas e outras são caras. Às vezes precisamos de provas, outras vezes apenas de indícios.
As pessoas descrevem isso das mais diferentes formas. Algumas seguem o ditado "fake it before you make it", que significa algo como "finja até conseguir". Outras pessoas enfatizam que você deveria construir coisas que não são escaláveis. O importante é aprendermos rápido e minimizarmos o desperdício (Waste).
Fazer uma equipe de desenvolvimento construir um produto real e lançá-lo no mercado para testar uma ideia é praticamente o método mais lento e caro de aprender algo.
7. Concentrar-se nos riscos principais
Na Product Discovery existem alguns pontos importantes que devemos considerar.
Primeiro, precisamos nos concentrar nos quatro riscos principais:
Valor – alguém compraria ou usaria este produto?
Usabilidade – os clientes entenderiam como usá-lo?
Viabilidade – nossos desenvolvedores conseguem construir o produto com a tecnologia, tempo e habilidades disponíveis na equipe?
Stakeholders – todos os envolvidos na empresa concordam com a solução proposta?
Product Discovery é a busca por boas respostas para essas quatro perguntas. Quando as encontramos, temos as evidências necessárias e estamos confiantes de que a equipe de desenvolvimento pode implementar e entregar uma solução de qualidade e escalável.
8. O Papel do MVP
O conceito do Minimum Viable Product é um dos conceitos mais importantes no desenvolvimento de produtos e, ainda assim, também é um dos mais mal utilizados e mal compreendidos.
Generalizar é sempre perigoso, mas vou me arriscar e afirmar que um MVP nunca deveria ser um produto. Toda vez que encontrei uma equipe que tinha investido muito tempo e dinheiro construindo um MVP, consegui mostrar a ela como poderia ter alcançado o mesmo aprendizado com custos muito menores e muito menos desperdício.
Um MVP é, portanto, um experimento – um teste. Normalmente é uma espécie de protótipo. Muitas vezes é um protótipo para o usuário, mas às vezes também um protótipo com dados reais ou usado para estudos de viabilidade. E às vezes é uma mistura dessas coisas. Em todo caso, é sempre apenas uma pequena parte do desenvolvimento de um produto real.
9. Product Delivery: Sem Compromissos no Release
Não se trata de dizer aos desenvolvedores como devem desenvolver e lançar software. Pelo contrário. Um problema que surge quando uma equipe de desenvolvimento precisa criar o MVP é que frequentemente se sente pressionada a lançar software em que não acredita. Eles não estão realmente comprometidos com aquilo. Talvez existam problemas de confiabilidade, escalabilidade ou performance, mas o gerente de produto simplesmente repete: "É só um MVP, relaxem!"
O que estou dizendo é que não devemos fazer concessões quando se trata de software do qual os clientes dependem para manter seus negócios funcionando. Existem muitas técnicas boas de Product Discovery para testar MVPs que protegem nossos clientes, nossa receita, nossa reputação e nossos colaboradores.
Portanto, use suas melhores práticas e só lance produtos quando tiver total confiança nesse release.
10. Ser obcecado pelo cliente
Este último ponto segue uma direção um pouco diferente. Em quase todas as empresas que visito, me dizem o quanto amam seus clientes. Isso geralmente faz parte dos valores ou da missão da empresa. Dizer isso é fácil, mas agir de acordo é bem mais difícil.
Percebo isso rapidamente quando converso com uma equipe. Como a equipe lida quando surge um problema com o cliente? Quão urgente isso é? A equipe entra em contato com o cliente para entendê-lo melhor, se necessário? Os membros da equipe conhecem os clientes pelo nome? Que tipo de relacionamento têm com os clientes? Os clientes são mais um incômodo ou são quase como colegas para os membros da equipe?
A melhor maneira de despertar verdadeira empatia e comprometimento com o cliente é fazer com que os membros da equipe (especialmente os desenvolvedores) entrem em contato direto com o cliente.
Espero que isso te ajude a desenvolver uma percepção melhor do que faz uma equipe de produto ser excelente.
Este texto é do blog de Marty Cagan e foi traduzido por nós para o português.
Outcome vs. Output
=> Entenda o Minimum Viable Product (MVP)
