Produto: É de comer ou de passar no cabelo?
Antes de iniciar uma carreira como produteira, eu precisei entender o que é produto.
Recentemente iniciei uma leve transição de carreira (sobre a qual falarei futuramente). Eu digo leve porque, apesar de ter mudado de função, eu continuo numa área muito próxima, trabalhando com desenvolvimento de software e realizando atividades que já realizava antes. Mesmo assim tive que aprender alguns conceitos e algumas ideias novas que eu já tinha ouvido falar, mas ainda não tinha me aprofundado, uma dessas o próprio conceito de produto.
Eu já tinha trabalhado com produto e realizado tarefas próprias de um gerente de produto, mas não sabia exatamente o que é um produto e o que o diferencia de outros conceitos comuns, como o de projeto ou serviço.
Agora, quase um ano depois que essa nova fase da minha carreira começou, quero compartilhar tudo que eu aprendi desde então para, quem sabe, poder ajudar outras pessoas que estão passando pelo mesmo caminho ou que estão indecisas sobre qual direção seguir.
Disclaimer: Este é um post introdutório sobre produtos e não pretende, de maneira nenhuma, ser exaustivo. Há vários outros temas que quero abordar a partir daqui, seguindo a minha própria evolução como Product Manager. Meu objetivo, neste momento, é me aproximar de quem está começando a trabalhar com produtos e também de quem não é da área, mas tem interesse em conhecer mais.
O que é um produto?
Durante toda minha vida profissional, ouvi que produto é aquilo que você pode tocar, algo tangível. Assim, como software não é físico, sempre considerei que o resultado do meu trabalho seria considerado um serviço. Não é bem assim. De acordo com as definições atuais, um produto tanto pode ser algo físico quanto algo virtual, enquanto um serviço pode ter características tangíveis. Não é isso que difere um do outro.
Então, o que define um produto?
Uma definição mais correta de produto poderia ser algo que, depois de construído, pode ser entregue ao seu consumidor final, de forma que este o utilize e desfrute de sua utilidade, seja ela qual for. Dessa forma, um produto pode ser um livro, que não necessita da assistência do autor para que seja lido, enquanto um serviço poderia ser um curso sobre o mesmo assunto ministrado pelo mesmo autor. Um produto também pode ser um alimento, enquanto um serviço associado seria a preparação e entrega desse mesmo alimento por um restaurante.
No mundo digital, temos vários tipos de produtos. O navegador que você utiliza para acessar a internet é um produto, o site que você acessa é um produto, os aplicativos do seu celular são produtos.
Para quem trabalha com desenvolvimento de software, a definição fica ainda mais abrangente, pois uma parte de um site, de um aplicativo, de um software qualquer pode ser considerada um produto independente. Por exemplo, no exemplo bastante comum do Spotify, existem times (ou squads) de produto autônomas para seções diferentes do site. Pode existir um squad que desenvolve os controles do player e outro squad que desenvolve as playlists, então, controles do player e playlists podem ser considerados produtos distintos nesse contexto. Ambos estão dentro do mesmo contêiner, chamado Spotify, mas oferecem um valor diferente para quem utiliza o software.
Generalizando, produto é qualquer pedaço de software que tenha alguma utilidade real, ou seja, que traga algum valor real aos seus usuários e que possa ser utilizado de maneira independente por estes.
Produto ou projeto?
Falei rapidamente sobre a diferença entre produto e serviço, mas essa não era a maior questão que me assombrava durante meus primeiros estudos. Para mim — uma pessoa que ama projetos e que trabalhou com eles durante todo o tempo — o mais difícil foi deslocar meu olhar focado em projetos para o olhar focado em produto. Se eu quisesse ser uma gerente de produtos, será que eu precisaria jogar fora tudo o que havia aprendido trabalhando com projetos nos últimos 16 anos?
Minha surpresa positiva foi que muitas das coisas que fazia antes, desde o início da minha carreira, ainda como programadora, também se aplicava à gestão de produtos; mas isso é assunto para outra conversa, voltemos à diferença entre os dois conceitos.
Uma das definições de produto, segundo o dicionário Michaelis, é a seguinte:
pro.du.to (sm)
O que é produzido, destinado ao consumo próprio ou ao comércio.
Por sua vez, projeto pode ser definido como:
pro.je.to (sm)
Plano detalhado de um empreendimento a ser realizado.
Ainda não é o suficiente, dado que o dicionário fala de maneira genérica, mas já é um indicativo. Produto é o destino, projeto é o caminho. Será?
O PMBOK, maior referência em gestão de projetos no mundo, confirma a suspeita.
Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Os projetos e as operações diferem, principalmente, no fato de que os projetos são temporários e exclusivos, enquanto as operações são contínuas e repetitivas.
Ok. Produto é o destino. Projeto é o caminho. E agora?
Para um leigo, essas definições não escondem nenhum grande segredo, mas há um detalhe que faz toda a diferença no desenvolvimento de software: O projeto é um esforço temporário.
Tradicionalmente, equipes de projeto realizavam um desenvolvimento do ponto A ao ponto B, preocupadas apenas em entregar o escopo contratado no tempo planejado. Após alcançarem o ponto B, o bastão era passado para a frente, as equipes eram desfeitas e as pessoas ficavam livres para trabalhar em outras coisas — outros projetos que teriam o mesmo destino. Quem vai implantar o produto? A equipe de infra do cliente, trabalhando no sábado à noite para gerar o menor impacto possível. Quem vai cuidar do produto? Provavelmente, uma equipe de sustentação, que receberá mini-projetos, chamados “demandas” ou “melhorias”, fará o que foi pedido e passará a trabalhar em outras demandas que podem ou não estar relacionadas.
Fazendo um paralelo com algo mais comum, imagine que o produto é um bebê. Nesse caso, o projeto é a gestação. Imagine que o acompanhamento pré-natal daquela gestante seja feito por um médico obstetra desconhecido, que só estará com ela durante as 40 semanas planejadas. Esse médico é o time do projeto. Agora, imagine que esse médico só trabalha em horário comercial, mas a mulher entrou em trabalho de parto na sexta à noite. Ela irá ao hospital e será acompanhada por uma equipe desconhecida, que só quer que aquele bebê nasça o mais rápido possível, para que possam seguir com as suas atividades. Para eles, é importante que o nascimento ocorra com segurança para a mãe e para o bebê, mas a saúde do bebê dali a um mês já está fora do escopo.
Se o Projeto Gestação fosse gerido como um produto, o time que conduz o pré-natal também teria que se preocupar com o que vem depois da conclusão do projeto — ou seja, depois do parto. Idealmente, esse time seria multidisciplinar e contaria com um pediatra para acompanhar a saúde do bebê, um ginecologista (que pode ou não ser o obstetra) para acompanhar a mãe e quaisquer outros profissionais que eles necessitassem pelo tempo que necessitassem.
Obviamente, existem inúmeras diferenças entre uma gestação e um projeto de software, mas esse é um exemplo fácil de assimilar. Se o produto que eu estou desenvolvendo é o meu bebê, eu me importo com ele, eu tenho o que a agilidade chama de ownership ou sentimento de dono. Embora não seja o único ponto que diferencia um projeto de um produto, é algo crucial.
Enquanto um time de projeto se preocupa com a eficiência (fazer certo e entregar no prazo), o time de produto se preocupa com a eficácia (fazer o que é certo).
Um dos produtos em que trabalho é o site SOS Me Poupe. No desenvolvimento de software tradicional, focado em projetos, eu me preocuparia apenas em terminar o site no prazo e entregar sem bugs. Mudanças são temidas, pois causam impacto no tempo. Em meus 11 anos como Analista de Negócios, foram incontáveis as vezes em que eu disse a um cliente que o que ele queria estava “fora do escopo do projeto”.
Por outro lado, como gerente de produtos, eu e meu time nos perguntamos constantemente se o que estamos fazendo será útil para quem está utilizando o site e, se não estiver, não vamos fazer, mesmo se isso tiver sido pensado lá atrás. Mudanças são bem-vindas, pois não quero apenas entregar um site que funcione, eu quero trabalhar em um site que ofereça uma boa experiência para as pessoas, que elas visitem com frequência, encontrem o que precisam, atraiam novas pessoas para utilizarem.
É importante entregar rápido, é importante fazer bem feito, mas de nada adianta ter um produto desenvolvido perfeitamente se ele não serve para nada.
