Frameworks de produto em contexto de dados
Toda a minha vivência de produto ocorreu no contexto B2B, mais especificamente trabalhando com produtos de dados. Nesse sentido, vários cursos falharam em me prover de ferramentas para trabalhar, principalmente no que diz respeito ao processo de discovery.
Ter sido cientista de dados no início da minha carreira me deu uma vantagem inicial para compreender problemas mais técnicos. Todavia, entendo hoje que essa experiência não precisa ser pré-requisito para nenhum PM se houver uma boa dose de criatividade, ou seja, a habilidade de traduzir problemas em uma estrutura simples que seja compreensível para todos os stakeholders.
Na minha experiência, o grande problema de desenvolver produtos de dados é a barreira linguística entre stakeholders de negócio e time técnico. É muito difícil traduzir para o negócio as etapas do desenvolvimento, e o negócio por vezes tem dificuldade para repassar a necessidade para os desenvolvedores.
Compilei alguns frameworks que tem funcionado para mim na prática:
- Matriz CSD
A matriz CSD é a grande coringa do PM. Funciona literalmente em qualquer situação e pode ser utilizada além do contexto de produto.
É muito útil para compreender como cada stakeholder vê o problema enfrentado e quais as pontas soltas de cada situação.
O que funcionou para mim foi rodar versões para cada um dos stakeholders e confrontar as dúvidas e certezas.
Muitas vezes fica claro que o time técnico não compreende a razão estratégica de certos desenvolvimentos e que o time de negócio não tem visibilidade da dificuldade técnica das soluções desenvolvidas.
3. 5W2H
Se o time técnico não compreende qual valor está gerando para o negócio, as soluções tendem a ser subótimas uma vez que se reduz a capacidade criativa do time.
Traga de forma clara para o time a resposta para perguntas simples como: por quê? para quem? quando? — e deixe o time livre para propor as soluções (o como?)
Acima de tudo, traga o que se quer medir ao final e deixe visível para o time o que de fato se quer impactar.
3. Gráfico adaptado de esforço x valor
Todo PM já viu o gráfico de duas dimensões que compara o esforço das iniciativas com o valor gerado.
É muito interessante misturar esse gráfico com conceitos de risco. Eu particularmente gosto muito dos 4 riscos mapeados pelo Marty Cagan (Técnico, Viabilidade, Usabilidade e Valor). Eu costumo também mapear “Prazo”, que sempre é de alto interesse dos stakeholders.
E não é necessário ter respostas exatas para cada uma dessas dimensões, apenas classifique de forma qualitativa (alto, médio, baixo) para trazer visibilidade para todos os interessados.
A mensagem que fica para qualquer PM, independente do contexto, é: seja criativo com os frameworks básicos e, acima de tudo, empodere o time. Traga todo mundo para a discussão e deixe o time técnico livre para dar opiniões. O time que compreende o problema de negócio realmente agrega valor e o PM criativo é aquele que consegue lidar com qualquer adversidade.
