Estratégia de Produto num Mundo Ágil

Recentemente conversei com uma equipe muito frustrada de engenheiros praticantes de Scrum. Eles estavam frustrados, pois sentiam que tudo que haviam feito no último ano era implementar funcionalidades e que o Gerente de Produtos não tinha nenhuma idéia do rumo que o produto deveria tomar ou o que eles estavam tentando atingir. Quando falei com o Gerente de Produtos (Product Owner, na linguagem do Scrum), ele explicou que ele acreditava que toda a sacada das de metodologias ágeis como o Scrum era poder se manter flexível e ágil, e que ele não achava que deveria se preocupar, ou se fixar, num rumo de longo prazo.

Esta não é a primeira vez que vi esta confusão, e temo que a estratégia de produto pode ter se tornado uma vítima não intencional da mudança para metodologias ágeis.

Pensei então que seria útil discutir o que é uma estratégia de produto, por que é tão importante fazê-la e como ela é, de fato, completamente compatível com uma filosofia ágil.

Primeiro, uma estratégia de produto deve descrever a visão daquilo que você está tentando alcançar. Usualmente, o intervalo de tempo entre dois e cinco anos. É um trabalho visionário e que deve ser persuasivo. Definitivamente não é nenhum tipo de especificação.

Algumas vezes a estratégia de produto é articulada na forma de uma página web no Wiki, algumas vezes é um documento, algumas vezes é um conjunto de slides no PowerPoint, e outras na forma de um vídeo seu evangelizando a visão. Em parte, o meio depende de quantas pessoas precisam ser comunicadas de sua estratégia de produto, e se você pode apresentar pessoalmente ou se deve ser enviada “empacotada”. De qualquer modo, ela deve ser clara, comprometedora e inspiradora. Como as coisas irão melhorar quando este produto ou serviço atingir seu potencial? Não é sobre as funcionalidades específicas que podem ou não ser construídas, mas sobre os benefícios de possuir este produto. Que problemas serão resolvidos com este produto? Porque os usuários adorarão o produto? Como o mundo será melhor uma vez que esta visão se torne realidade?

Em segundo lugar, a estratégia de produto é a ponte entre a estratégia do negócio e o roadmap do produto. A estratégia do produto deve suportar a estratégia de negócios, e o roadmap do produto é o que descreve seu plano atual de como irá de onde está agora, para a visão descrita em sua estratégia de produto.

Assegure-se de não confundir a estratégia do negócio com a estratégia do produto. A estratégia do negócio pode ser algo como “expandir nossa oferta de comércio eletrônico para permitir clientes na Europa e Ásia”. A estratégia do produto pode então descrever a eventual oferta de comércio eletrônico que tenha o suporte a línguas estrangeiras, a conversões de moeda, métodos de pagamento, entrega, controle de impostos, etc. que você precisará para suportar a estratégia de negócios.

Em terceiro, ter uma boa estratégia de produto é uma das coisas mais importantes que um Gerente de Produtos (ou, muito freqüentemente, o Diretor de Produtos) faz. Não é fácil, mas sem isso você pode ter pouca esperança de terminar com um produto que valha a pena. É como o antigo ditado que diz que se você não sabe para onde está indo, qualquer caminho serve.

Temos uma estratégia de produto ao obter um profundo conhecimento de nosso público-alvo, do mercado e das tecnologias envolvidas. Haverá brainstormings e montes de debates. Você deve ativamente envolver seus líderes de design e líderes de engenharia nesta discussão, bem como os principais stakeholders. A estratégia de produto é algo que você irá discutir e rever ativamente com sua gerência. Seu time executivo deve se preocupar profundamente com esta estratégia de produto.

Muitos Gerentes de Produto cometem o erro de acreditar que a estratégia de produto deve vir de cima para baixo, e em alguns casos isso acontece, especialmente caso você esteja numa startup com o fundador fazendo o papel de visionário do produto. Mas caso contrário, você precisa propor a estratégia de produto e oferecê-la para sua gerência para sua aprovação. É uma grande oportunidade para você subir na carreira.

Mas definir e construir funcionalidades sem uma estratégia de produtos bem pensada é, muito provavelmente, perda de tempo e dinheiro.

Em quarto lugar, é essencial compreender que a estratégia de produto não lhe prende a nenhuma funcionalidade (ou seqüência de funcionalidades) em particular. A seqüência e as funcionalidades são representadas no roadmap de produtos (o backlog no linguajar do Scrum). Você pode (e certamente deve) ajustar o roadmap constantemente com base no que você aprende de seus usuários, do mercado, suas análises e as novas tecnologias sobre as quais o produto é construído.

Finalmente, descobri que criar um conjunto de princípios de produto que acompanham sua estratégia de produto ajudará você e o time de produtos a tomarem as muitas decisões e trade-offs que surgem quando você realmente define as funcionalidades e a experiência do usuário. Os princípios de produto vão junto com e suportam a estratégia de produto. Você pode ler mais sobre princípios de produto em http://www.svpg.com/blog/files/product_manifesto.html.

Se tudo correu bem você já pode ter a noção de que ter uma visão daquilo que você está tentando atingir não é de forma alguma inconsistente com os princípios das metodologias ágeis. Defendo que as metodologias ágeis aplicadas corretamente lhe ajudarão e tornar sua estratégia de produto uma realidade mais rapidamente que com as metodologias tradicionais.

Se você não tem uma estratégia de produtos para seu produto, recomendo fortemente que você pare, de um passo para trás, e se pergunte o que está tentando realizar. Em uns três anos, o que você quer que este produto seja? Como você irá medir e reconhecer isto? Compartilhe esta visão com sua gerência e seu time de produtos, especialmente seus engenheiros. Eles também querem saber para onde o produto está se direcionando. Ajudará a mantê-los motivados, eles terão alguma fé de que você, como Gerente de Produtos, não está apenas atirando no escuro, e a estratégia é importante também porque ajuda os engenheiros a anteciparem as necessidades futuras que podem impactar suas escolhas em tecnologia e arquitetura.