Times de produtos estão cada vez mais em evidência. É muito comum encontrarmos esses times, não importa o tamanho ou o segmento de atuação das empresas nos quais estão inseridos.

Este artigo é o primeiro da série na qual abordaremos conceitos relacionados ao nosso time de produtos. Dividiremos os assuntos nos seguintes tópicos:

Parte I: Por que criamos um time de produtos.

Parte II: Como aplicamos o conceito de MVP.

Parte III: Qual é a real influência dos dados nas nossas decisões estratégicas.

Introdução

Antes de iniciarmos a discussão sobre o nosso time de produtos, cabe uma pequena introdução sobre a empresa em que estamos inseridos.

A MZ é uma empresa líder no mercado brasileiro no setor de relações com investidores, com 19 anos de existência e consolidação no mercado. Nosso principal objetivo é cumprir integralmente o nosso propósito de facilitar e agregar cada vez mais valor aos nossos clientes. Nesse contexto, vimos a necessidade de mudar o rumo da companhia.

Decidimos, então, preparar a empresa para um mundo cada vez mais rápido e digital. Com esse foco, iniciamos os processos de transformação digital e cultural. Nesse processo, desenhamos toda a operação da empresa ao redor dos novos produtos que estamos construindo. Para isso, investimos em tecnologia de ponta e alteramos a maneira como trabalhávamos até então.

Uma das primeiras ações efetivas que executamos foi a criação do nosso time de produtos, que passou a ser responsável pelo novo posicionamento.  

Para entender o que essa mudança representa, é essencial olharmos para o nosso passado. Durante muito tempo, nossas equipes foram divididas da seguinte forma:

Equipes de negócios: responsáveis por identificar as necessidades dos nossos clientes e assegurar que todas as suas necessidades fossem atendidas.

Equipes de tecnologia: responsáveis pela manutenção dos produtos existentes e pelo desenvolvimento de novas funcionalidades especificadas pela equipe de negócios.

Este modelo, apesar de utilizado por diversas empresas, possui algumas falhas, das quais podemos destacar:

• A equipe de negócios não possui o conhecimento necessário em tecnologia. Com isso, acabam surgindo diversos produtos “fantasmas” que não conseguem ser reaproveitados e demandam manutenções futuras, além de custos para a empresa.
• A equipe de tecnologia não possui entendimento claro do possível crescimento dos produtos; dessa forma, as decisões estratégicas raramente são efetivas.
• Documentação extensa e dificuldade de controle: Em um mundo ágil e de mudanças, a entrega precisa ser rápida. Transformar manutenções em megaprojetos causa um transtorno para todos os envolvidos (cliente e equipes internas).
• Dificuldade de atualização: O processo de criação de novas ferramentas e de atualização das tecnologias existentes se torna extremamente difícil. São muitas regras de negócio espalhadas por todas as aplicações criadas.

Ao olharmos o cenário, percebemos a extrema necessidade de termos um controle mais rígido dos nossos produtos e assegurar que somente funcionalidades efetivamente relevantes fossem desenvolvidas.  

Ao analisar o mercado e as empresas atuais, deparamo-nos com diversos exemplos de funcionamento. Dois exemplos chamaram a nossa atenção e resolvemos estudá-los a fundo para aplicar seus conceitos na nossa empresa: Spotify (Squads) e Google (OKRs).

Estrutura da equipe (Squads)

O requisito básico para atingirmos a excelência é termos profissionais com diferentes qualificações trabalhando juntos, em prol de um propósito. Assim, criamos um time de produto composto por:

Os principais desafios desse time são de assegurar que a equipe de desenvolvimento produzirá somente aquilo que trará valor aos nossos clientes e que poderá ser escalável e replicável, bem como analisar todos os dados gerados pela plataforma e tomar decisões sobre as features existentes (alterá-las se necessário ou até mesmo descontinuá-las).

O fato de termos uma equipe multidisciplinar é fundamental para o cumprimento dos nossos objetivos. Conseguimos analisar o produto de ponta a ponta, entendendo se é possível criá-lo com a tecnologia existente (especialistas técnicos), se ele trará benefícios ao mercado que buscamos (especialistas RI), se está bem desenhado/estruturado, se será aceito pelo público (especialista UX) e se o momento para o seu lançamento é oportuno (líder).

Prototipação e validação

Há muitas literaturas sobre como deve ser a rotina de um time de produtos. Optamos por seguir os ensinamentos do Google Ventures (GV), que podem ser encontrados neste endereço: http://www.gv.com/sprint/

Nossos sprints, assim como o do GV, são divididos em cinco dias. Cada dia possui suas atividades específicas e no final da semana (sexta-feira), conseguimos aprovar ou não a nossa ideia. Caso seja aprovada, essa funcionalidade segue para o time de desenvolvimento para ser implementada.

De forma bem resumida, para novas funcionalidades, trabalhamos com o princípio de que não há necessidade de implementação sem validação prévia. Dessa forma, concentramos nossos esforços em discutir quais regras de negócio devem ser atendidas e qual é a melhor forma de atendê-las.  

Após definirmos o que deverá ser entregue, criamos protótipos funcionais e o validamos com clientes e com outros especialistas. Se tivemos o aval de mais de 75% do nosso público-alvo, seguimos em frente.

A única regra que não seguimos à risca é o tempo desprendido. De acordo com o GV, seria necessário trabalharmos focados por pelos menos seis horas diárias. Devido ao fato de  termos uma operação enxuta e outras obrigações, dedicamos apenas um período diário. Apesar disso, não nos sentimos prejudicados e a nossa taxa de retrabalho em desenvolvimento diminuiu drasticamente.

Mensuração e manutenção

Para as funcionalidades já desenvolvidas e em uso, não existe nada mais assertivo do que dados. Conseguimos colher informações diversas sobre utilização, tempo despendido em cada ação, facilidade de uso, dentre outros.

Com isso, sugerimos mudanças diversas (layout, fluxo de informação ou até mesmo regras de negócio) e validamos tais alterações com os nossos clientes/público interno antes de implementá-las.

O mais incrível de se trabalhar com dados é que, em mais de 95% dos casos, as mudanças sugeridas são muito bem aceitas e elogiadas. Assim, economizamos o tempo gasto em correções de bugs e podemos investir corretamente na criação de novas funcionalidades.

Os dados, no entanto, não dispensam a necessidade de interação com seu cliente. É sempre muito importante ouvir o cliente e validar suas solicitações. Para isso, utilizamos uma ferramenta de feedback, um Google Forms com quatro perguntas. Essas perguntas permitem que a solicitação/sugestão seja feita de forma estruturada. Evitamos, assim, o tradicional: “Seria muito legal se…” e trocamos a sugestão incerta por algo que realmente trará valor para quem a solicita.

Conclusão

O mundo está mudando. Novas tecnologias surgem a cada hora e precisamos estar preparados para alcançar a excelência e utilizar o que existe de mais moderno. É impossível inovarmos, melhorarmos e evoluirmos se ficarmos engessados em processos antigos e ultrapassados. A criação de um time de produtos como o nosso pode agilizar e assegurar a rapidez necessária para as evoluções e adequações necessárias.

Outro ponto importante é sempre colher dados em qualquer implementação realizada. Falaremos mais sobre isso no terceiro artigo desta série.

No próximo artigo, falaremos sobre como trabalhamos o conceito de MVP e como ele nos ajudou a economizar horas e mais horas no desenvolvimento dos nossos produtos.

Escrito por: Felipe Furlan