Mentalidade de produto x mentalidade de projeto
Um dos maiores desafios que Product Managers vão encontrar é tentar transformar a mentalidade e a cultura baseada em projeto para uma abordagem de produto.
Por Kyle Evans (publicado originalmente aqui, em inglês)
Project Thinking
Project Thinking, (Mentalidade de Projeto, em português) é algo bem universal. Muitas pessoas, especialmente no desenvolvimento de softwares, passaram uma boa parte de suas carreiras focadas em projetos e gestão de projetos. Grandes empresas geralmente têm departamentos de PMO, (acrônimo de Project Management Office, comumente traduzido para o português como Gestão de Projetos) focados exclusivamente na, obviamente, gestão de projetos. Não é surpresa, uma vez que a gestão de projetos existe há muito tempo. E nós humanos tendemos a pensar em termos de projetos: as coisas precisam ser feitas.
O que é project thinking de fato?
O foco é a entrega. Pode ser a entrega de features específicas de um software, ou na verdade, a entrega de qualquer coisa. De aviões a casas. E devido ao foco estar na entrega, a medição primária é feita na timeline e nos prazos.
A gestão de projetos tem como foco especialmente o resultado, e é medida pela precisão em estimar um cronograma antecipadamente e, então, entregar o resultado concreto especificado naquele prazo. O sucesso depende muito de coletar as especificações anteriormente, montar uma agenda com metas distribuídas no período e, então, cumprir essas metas.
Product Thinking
Product Thinking, (Mentalidade de Produto, em português) parte de um pressuposto fundamentalmente diferente. Ao invés de focar no resultado, pensar o produto significa pensar no objetivo.
Isso é uma mudança significativa de mindset ao pensar em termos de projeto. Em vez de focar em cronogramas e prazos, nós passamos a focar no objetivo que queremos alcançar ou no trabalho que precisa ser feito.
Pelo fato de estarmos focadas no objetivo ao invés do resultado, é muito mais difícil colocar parâmetros de tempo na entrega, pelo menos no começo. Primeiramente porque nós não necessariamente sabemos como vamos atingir a meta logo no começo. Esse tipo de pensamento pode significar uma grande mudança, especialmente para pessoas que passaram muito tempo focadas em projetos e gestão de projetos. Muitas pessoas se sentem desconfortáveis com a incerteza de não ter timelines estruturadas e prazos que elas possam monitorar regularmente.
Os benefícios
Quais são os benefícios de abandonar as timelines de projetos em detrimento do foco no objetivo final?
Primeiramente, é sempre o objetivo que nos guia, independentemente de como nós tentamos chegar lá. O principal benefício de um mindset de produto é a garantia de que chegamos ao objetivo final da forma mais eficiente possível.
Com um mindset de projeto, nós assumimos que no começo já sabemos como alcançar a eficiência desejada. Trabalhando a partir desse pressuposto, nós criamos um plano de projeto e uma timeline repleta com os requerimentos e metas, e então começamos a execução desse plano.
Se estivermos certas, e o que pensamos inicialmente for a solução correta, então ótimo. Apenas executamos o plano e chegamos ao objetivo. Mas e se estávamos errados desde o começo? E se a solução que nós identificamos não atingir o objetivo que esperávamos?
É aí que pensar em termos de projeto nos coloca em todo tipo de apuros. Uma vez que colocamos o plano em ação, pode ser muito difícil, especialmente em grandes organizações, pivotar e mudar. Uma vez que as datas foram estabelecidas e todo mundo concordou com o plano, é geralmente isso que fica gravado na mente de todos, apesar dos nossos melhores esforços de aprendizado e adaptação. E se nós acabamos perdendo um prazo, isso pode causar problemas enormes para as equipes e para os negócios.
Mas, com um mindset de produto, somos capazes de aprender e nos adaptar no meio do processo.
Não estamos presos em prazos e metas, mas focados em aprender e atingir o objetivo final. Se algo não funciona ou os clientes não respondem bem a alguma coisa, podemos levar isso em conta, adaptar, e ainda trabalhar em direção ao objetivo inicial sem jogar fora um belo plano que já está no foco de todos.
Isso é crucial, porque quando os problemas surgem (e não se engane, eles sempre surgem) pensar em termos de produto nos permite aprender e adaptar, e ficar focados no objetivo que estamos tentando atingir. Em contraste, quando os problemas surgem e estamos presos ao pensamento de projeto com foco na timeline, geralmente iremos ficar restritos a reuniões intermináveis tentando determinar porque nossos palpites iniciais estavam errados e como nós podemos voltar para o cronograma.
Isso leva, por fim, a sacrifícios na qualidade, no equilíbrio vida pessoal-trabalho e em eficiência de ação, já que precisamos nos manter focados em entregar o resultado inicialmente combinado (independente de ser a coisa certa a se fazer).
Um exemplo de projeto
Temos falado muito sobre conceitos, então vamos olhar alguns exemplos para ilustrar melhor estes pontos.
Um grande exemplo de um projeto é a construção de uma casa. Minha esposa e eu construímos nossa casa no ano passado. Passamos por todo o processo de escolher a planta baixa, os acabamentos e detalhes da casa, e então pagamos grandes parcelas para manter a coisa andando.
Quando começamos, nosso empreiteiro (que era excelente), nos deu uma data estimada de conclusão. Era algo como dali a seis meses. Obviamente havia muitas coisas que entravam nessa estimativa e muita coisa ainda ia atrasar os prazos, mas já que a construção de uma casa é um processo bastante repetitivo com etapas bem definidas, um bom empreiteiro pode olhar para um cronograma semanal e determinar quando eles esperam terminar o trabalho.
A casa ficou pronta com uma semana de atraso, o que parece ser uma precisão incrível, na minha opinião. Uma das entregas atrasou o trabalho deles em alguns dias, o que teve um efeito dominó. Mas tudo bem, era esperado.
Nesse tipo de projeto de construção, muita coisa é orientada pela gestão do projeto. Todo mundo sabe o que precisa ser feito e manter as pessoas no prazo é um ponto chave, especialmente pelo fato de que não era só a nossa casa sendo feita, mas todo um condomínio.
Um exemplo de produto
Mas esse tipo de gestão de projeto funciona em todos os casos?
Não, não funciona.
Por mais que nos agrade pensar no desenvolvimento de softwares como uma construção, eles não são bem isso. Os planos e os trabalhos bem definidos não se encaixam no desenvolvimento de produtos, não importa o quanto nós tentemos. Mesmo sendo bem confortável ter timelines bem definidas, não é como devemos gerenciar o desenvolvimento de produtos.
Em um produto de apresentação de portfólio com foco em estudantes em que tenho trabalhado, identifiquei um problema crucial e soube o que precisaríamos resolver para continuar a aumentar nosso público e alcançar mais pessoas. A abordagem tradicional seria reunir requerimentos, fazer o escopo do trabalho e então desenvolver os features. Mas para a consternação de muitos colegas de trabalho, eu não uso a abordagem típica.
Uma vez que eu identifiquei o problema, eu me debruço sobre soluções possíveis, desde o desenvolvimento de features até integrar um terceiro software. Como eu fiz isso, ficou claro para mim que a solução era, de fato, não desenvolver nada. Ao invés de acrescentar novas features ou integrar o software de um terceiro, a solução foi modificar o que estávamos pedindo para as próprias estudantes fazerem.
Ao invés de focar na ferramenta do portfólio, nós podíamos simplesmente pedir que elas criassem peças do portfólio e então usar qualquer software que quisessem para mostrar seus trabalhos. Os benefícios para todos seriam significativos. Estudantes estariam no controle do seu portfólio, e não estariam amarrados a criar softwares ou usar nenhum fornecedor específico.
Nós nunca teríamos chegado a essa solução com um pensamento de projeto. Essa solução surgiu porque eu estava focado no problema e o objetivo (trazer mais pessoas usuárias para o aplicativo) ao invés de construir a próxima feature.
Este tipo de resultado é tipicamente o objetivo de pensar em termos de produto. E isso pode surgir em qualquer momento. No exemplo que eu citei, nós evitamos fazer qualquer trabalho de desenvolvimento. Mas geralmente isso pode custar alguns designs de protótipo até se descobrir o que vai funcionar. Ou nós podemos fazer pequenos trabalhos de desenvolvimento para aprender quais features irão de fato levar ao objetivo que nós queremos.
Não importa em que momento isso acontece, mas a chave é que estamos aprendendo conforme caminhamos, mais do que decidindo o curso logo de início e seguindo um plano de projeto.
A maneira certa
Então, como fazemos isso? Como mantemos o foco na mentalidade de produto?
Todos os produtos e a gestão de produtos envolvem algum nível de gestão de projeto. O ideal é manter as coisas caminhando e é (infelizmente) irreal assumir que é possível trabalhar em ambientes onde nossos stakeholders e parceiros não vão esperar algum prazo ou compromisso.
O segredo é assumir compromissos e planos de projetos apenas no momento em que podemos fazer isso com um alto grau de confiança. Então, ao invés de nos comprometermos com um caminho específico de antemão, nos comprometemos uma vez que validamos o que estamos fazendo e tivermos tido a chance de verdadeiramente entender o que vai ser necessário.
Geralmente, isso se decide em uma ou duas sprints no trabalho. Pode parecer tardio no processo, mas é o ponto em que estimativas e planos podem, de fato, significar alguma coisa.
Marty Cagan, em seu livro Inspired: How to Create Tech Products People Love, chama esse tipo de compromisso de “compromisso de alta integridade”. Nós permitimos as equipes fazerem uma descoberta adequada e pesquisar antes de pedir qualquer tipo de definição.
E também precisamos ajudar as outras pessoas a entender os benefícios de pensar em termos de produto. Há uma razão pela qual muitas pessoas pedem prazos e timelines. Parte disso se dá por conta de velhos hábitos. Mas há momentos em que é necessário para os negócios e para a previsão de orçamento de uma empresa. Logo, precisamos entender qual é o papel da timeline nesses casos.
Se é para ajudar a vender o produto, nós devemos mudar o foco das features específicos para um nível mais alto. Se é para fazer gestão de risco, talvez nós precisemos ajudar as pessoas a entenderem que o risco real não é perder um prazo, mas perder completamente o sentido de valor estamos tentando entregar.
No fim do dia, todo o propósito do desenvolvimento de produto é entregar valor às pessoas usuárias e consumidoras. A maior parte do tempo, nós não sabemos exatamente o que vai funcionar até entregar esse valor.
Pensar que podemos apresentar as soluções ideias logo no começo do projeto e fazer projeções longas (às vezes anuais) de planejamento e de budget necessários é bem irrealista.
Enquanto pensar em termos de projeto foca em trazer soluções dogmáticas desde o início e em fazer entregas com base em um cronograma, pensar em termos de produto mantém o foco no objetivo final. Isso envolve algum nível de conforto com a incerteza e com o aprendizado, o que pode ser bem difícil. Mas se queremos atingir o objetivo correto, e não só um resultado dentro do prazo, essa é a única forma de fazer.
