Qual a diferença de Produto e Projeto

Um dos maiores desafios que um gerente de produto (ou empresa) enfrentará é tentar elevar o pensamento e a cultura de um nível de projeto para um nível de produto. Mais você sabe qual a diferença de produto e projeto?

• Pensando como projeto

O pensamento do projeto é bastante difundido. Muitas pessoas, especialmente no desenvolvimento de software, passaram suas carreiras focadas em projetos e gerenciamento de projetos (aprenda a entender o que seu time de desenvolvedor quer dizer).

As grandes empresas geralmente têm departamentos de PMO, focados exclusivamente no gerenciamento de projetos. Isso não é uma surpresa, já que o gerenciamento de projetos já existe há muito tempo. E nós, como seres humanos, tendemos a pensar em termos de projetos: coisas que precisamos fazer.

Essa é a principal diferença de produto e projeto: O foco do projeto é a entrega. Pode ser a entrega de features, software específicos ou realmente a entrega de qualquer coisa. De aeronaves até casas. E como o foco é a entrega, a medida principal está na linha do tempo e no cronograma.

O gerenciamento de projetos concentra-se especificamente na produção e é medido pela precisão com que conseguimos estimar tempo necessario com antecedência e, em seguida, entregar a produção especificada nesse cronograma. O sucesso é amplamente definido como pegar as especificações de algo de antemão, estabelecer um cronograma com milestone ao longo do caminho e depois atingir essas datas.

O foco do projeto é a entrega

• Pensando como produto

O pensamento de produto adota uma abordagem fundamentalmente diferente. Em vez de focar na entrega, o pensamento do produto está focado no resultado.

O foco do produto é o resultado

Essa é uma mudança significativa da mentalidade do pensamento do projeto. Em vez de focar em cronogramas e datas, focamos no objetivo que queremos alcançar ou no trabalho a ser realizado. Como estamos focados no resultado e não na entrega, é muito mais difícil colocar restrições de tempo na entrega, (pelo menos antecipadamente). Principalmente porque não sabemos necessariamente como vamos atingir a meta antecipadamente.

Esse tipo de pensamento pode ser uma grande mudança, especialmente para pessoas que passaram muito tempo focadas em projetos e gerenciamento de projetos. Muitas pessoas ficam desconfortáveis com a incerteza de não ter cronogramas estruturados que possam monitorar regularmente.

Importante: Isso não quer dizer que a entrega não é importante! Isso quer dizer que quando estamos pensando como produto, o foco passa a ser no resultado do que estamos fazendo, e não somente na entrega. Mas para termos o resultado esperado ainda precisamos entregar o que foi planejado.

Primeiro de tudo, uma das diferença de produto e projeto é que o nosso foco passa a ser no resultado, independentemente de como fazemos para chegar lá. O principal benefício de uma mentalidade de produto é garantir que cheguemos ao resultado com mais eficiência.

Com uma mentalidade de projeto, assumimos no início que já sabemos como alcançar o resultado desejado. Trabalhando com essa premissa, criamos um plano de projeto, uma linha do tempo cheia de requisitos e milestone (conheça 5 fontes de idéias para seu roadmap) e, em seguida, iniciamos a execução desse plano. Se estivermos certos, e o que assumimos inicialmente for a solução certa, ÓTIMO. Apenas executamos o plano e alcançamos o resultado.

Mas e se estivéssemos errados inicialmente? E se a solução que identificamos não atingir o resultado esperado?

É aí que o pensamento do projeto nos cria problemas. Uma vez que definimos um plano é muito dificil mudar, especialmente em empresas maiores (isso não quer dizer que você que você vai deixar seu roadmap a merce de features sorrateiras).

Depois que as datas são definidas e todos concordam com um plano, geralmente é isso que fica na mente de todos, apesar dos nossos melhores esforços para aprender e se adaptar. E se acabarmos perdendo uma data, isso pode causar problemas incríveis para as equipes e empresas.

Mas com uma mentalidade de produto, somos capazes de aprender e nos adaptar à medida que avançamos. Não estabelecemos datas e milestones, mas estamos focados em aprender e alcançar o resultado. Se algo não der certo ou os clientes não responderem bem a uma coisa, podemos levar isso em conta, adaptar e ainda trabalhar para o resultado pretendido sem jogar fora um plano lindo que todos estão esperado.

Fundamentalmente, quando os problemas surgem (e não se enganam, eles sempre surgirão), o pensamento do produto nos permite aprender, nos adaptar, e manter o foco no resultado que estamos tentando alcançar. Por outro lado, quando surgem problemas e estamos presos ao pensamento do projeto, com foco no cronograma, muitas vezes somos sugados para reuniões sem fim, tentando determinar por que nossas suposições iniciais estavam erradas e como voltamos ao plano inicial.

Quando os problemas surgem, o foco no produto nos permite aprender, adaptar e manter o foco no resultado que esperamos alcançar.

Em última análise, isso leva a sacrifícios em qualidade, equilíbrio entre vida profissional e resultado, uma vez que precisamos permanecer focados em fornecer os resultados que concordamos inicialmente (independentemente de isso ainda ser a coisa certa a fazer).

Um exemplo de projeto – construindo uma casa

Tudo que disse até agora sobre a diferença de produto e projeto foi muito teorico e conceitual, então vamos dar uma olhada em alguns exemplos práticos para ilustrar melhor esses pontos.

Um ótimo exemplo de projeto é a construção de uma casa. Quando vamos construir uma casa, nós passamos por todo o processo de seleção da planta baixa, da escolha os acabamentos e detalhes da casa e, em seguida, do pagamento de grandes quantias de dinheiro para que ela continuasse.

Quando vocé começa a construir, o engenheiro que você contratou (que é excelente) te deu data estimada para o término – 6 meses no total. Obviamente, há muitas coisas que entram nessas estimativas, e muitas vezes surgem coisas que atrasam as datas, mas como a construção de uma casa é um processo muito repetitivo com processos definidas, um bom gerente de construção pode analisar o plano semana a semana e determinar quando eles esperam concluir o trabalho.

Quando se trata desses tipos de projetos de construção, eles são muito voltados para o gerenciamento de projetos. Todo mundo sabe o que precisa ser feito e manter as pessoas dentro do cronograma é a chave do sucesso.

Um exemplo de produto

Mas esse tipo de gerenciamento de projetos funciona em qualquer lugar? Não, não funciona!

Por mais que gostemos de pensar em desenvolvimento de software como construção, ele não é. Os planos e o trabalho claramente definidos não se traduzem no desenvolvimento de produtos, por mais que tentemos. Embora exista um grande conforto em prazos bem definidos, não é assim que devemos desenvolver o produto.

Em um produto em que estou trabalhando, há um problema-chave que identifiquei e sabia que precisávamos resolver para ampliar nosso público-alvo e alcançar usuários adicionais. A abordagem tradicional para isso seria reunir os requisitos, definir o escopo do trabalho e criar as features. Mas, para grande surpresa de muitas pessoas na minha empresa, eu não adoto esse tipo de abordagem.

Depois de entender o problema, comecei a pesquisar soluções, desde a criação das features até a integração de software de terceiros. Ao fazer isso, ficou claro para mim que a solução era, na verdade, não criar nada. Em vez de criar novas features ou integrar o software de outra pessoa, a solução era mudar o que estávamos pedindo aos clientes.

Nunca teríamos chegado a essa solução com o pensamento de projeto. Essa solução surgiu porque eu estava focado no problema e no resultado (obtendo usuários adicionais em nosso aplicativo) em vez de criar a proxima feature.

Conseguimos esse tipo de resultado com o foco no produto. E pode vir a qualquer momento ao longo do caminho. No meu exemplo acima, evitamos fazer qualquer trabalho de desenvolvimento. Mas muitas vezes pode levar vários protótipos de design para descobrir o que funcionará. Ou podemos fazer pequenas quantidades de trabalho de desenvolvimento para aprender quais features realmente direcionarão o resultado que queremos.

Não importa em que parte do processo aprendemos, a chave é aprender ao longo do caminho, em vez de decidir o curso antecipadamente e seguir um plano de projeto.

Todos os produtos e gerenciamento de produtos envolvem algum nível de gerenciamento de projetos (conheça 7 principios que você pode usar como gerente de produto).Temos que manter as coisas em andamento e (infelizmente) não é realista supor que podemos trabalhar em um ambiente em que nossos stakeholders e parceiros não esperem datas ou compromissos.

Todos os produtos e gerenciamento de produtos envolvem algum nível de gerenciamento de projetos.

A chave é assumir compromissos e planos do projeto apenas em um momento em que possamos fazê-lo com um alto grau de confiança. Portanto, em vez de nos comprometermos com um caminho específico de antemão, nos comprometemos somente depois de validar o que estamos fazendo e ter a chance de realmente entender o que será necessário.

Muitas vezes, isso é um ou dois sprints do desenvolvimento. Isso pode parecer muito tardio no processo, mas é no momento em que estimativas e planos podem realmente 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“. Damos tempo às equipes para fazer descobertas e pesquisas adequadas antes de pedir compromissos.

E também precisamos ajudar outras pessoas a perceber os benefícios do pensamento no produto. Há um motivo pela qual muitas pessoas solicitam datas e cronogramas – parte disso é por causa de velhos hábitos, mas há momentos em que é necessário para o negocio e orçamentos. Portanto, precisamos entender qual é o objetivo do crongorama nesses casos.

• Se é para ajudar a vender o produto, devemos mudar o foco de features específicos para a história de usuarios de nivel superior.
• Se é para gerenciar riscos, talvez seja necessário ajudar as pessoas a entender que o risco real não é perder uma data, é sim errar completamente no valor que estamos tentando oferecer.

No final do dia, não existe uma diferença o objetivo do desenvolvimento de produtos é agregar valor aos usuários e clientes. Na maioria das vezes, não sabemos exatamente o que vai entregar esse valor. Pensar que podemos encontrar as soluções certas antecipadamente (às vezes com um ano de antecedência, se você faz um planejamento e orçamento anuais), é bastante irrealista.

A principal diferença de produto e projeto é que enquanto o pensamento do projeto se concentra em apresentar soluções antecipadamente e, em seguida, cumprir um cronograma, o pensamento do produto mantém o foco no resultado. Isso exige um nível de conforto com a incerteza e o aprendizado, o que pode ser bastante difícil. Mas se queremos chegar ao resultado certo, e não apenas a uma produção pontual, é realmente a única maneira de trabalhar.

Espero que tenha gostado do artigo e que ele tenha te ajudado a entender a diferença entre produto e projeto, e como você pode tirar o melhor de cada mundo para sua empresa. Se quiser saber mais sobre as características de um time de alta perfomance e como usar suas habilidades para priorizar as feature e criar um roadmap, continue explorando! Espero que encontre o que esta buscando aqui no “vida de produto”.