Ao assumir um produto, um dos maiores desafios de um PO é encontrar uma forma de fatiar os testes de hipótese e entregar valor para o cliente desde o primeiro momento.
Para isso, o PO deve ser apaixonado pelo problema que ele tem a resolver, e não pela solução. Ele deve fatiar este problema, e encontrar pedaços deste problema que ainda agregam valor para então testar suas hipóteses de solução.
Há alguns (vários) meses, um amigo me disse “você tem que escrever um livro”. A princípio, como boa parte do que fazemos é de cunho prático, questionei. Não sabia se formatar o conhecimento em um livro resolveria um problema relevante para quem trabalha com produtos. Antes de mais nada, eu precisava entender qual era o problema que eu queria resolver. Então comecei a pensar em hipóteses.
Eu precisava tratar meu livro como um MVP.
A primeira coisa que eu precisava validar era quais os maiores problemas enfrentados pelos times de produto. Com base na experiência de coaching de produto para POs, meu backlog tinha os seguintes itens priorizados:
- como defino o problema ou problemas que quero resolver com meu produto?
- como entendo o contexto dos meus stakeholders?
- como faço com que todos os stakeholders estejam na mesma página, por um objetivo em comum?
- como posso conhecer melhor os clientes do meu potencial produto?
- como levantar uma visão de produto?
- como montar uma primeira versão de backlog?
- tendo esta versão, como priorizá-la?
Para isso, conversei com todos os POs e times de produto que pude, buscando entender se esses eram os maiores problemas, onde estavam as maiores dores e tentando identificar que técnicas poderiam ajudar para cada uma delas.
Note que até aqui não escrevi uma linha.
Depois, precisava ter certeza que as técnicas que eu ofereceria funcionavam na prática, e poderiam ser ensinadas e reproduzidas. Para isso, apliquei 2 ou 3 modelos diferentes de workshop em eventos e meetups, com o objetivo de transmitir conhecimento e, por fim, colher feedback sobre se as técnicas aprendidas podiam ser reproduzidas e se eram úteis em diferentes cenários para viabilizar um product discovery.
Ainda nenhuma linha escrita. Mas já temos a construção de protótipos (os workshops) para validar hipótese.
Depois de ter feedback e fazer alguns ajustes, escrevi artigos (como este, este, e este) explicando algumas técnicas. Alguns leitores entraram em contato comigo, e fui acompanhando a aplicação, entendendo se o passo a passo estava claro, e o que poderia entregar mais valor em relação ao encadeamento das dinâmicas. Além disso, precisei entender quanto de teoria e explicação dos porquês era o suficiente para ajudar sem se tornar maçante.
Mais feedback, mais validações, mais descarte de itens que não resolviam os problemas. Mas nada do livro de fato escrito.
Para validar se o problema crucial a ser resolvido com o livro fazia sentido para meu público, escrevi um artigo que viria a se tornar a introdução, e fiquei atenta não apenas ao feedback, mas aos compartilhamentos e à taxa de leitura. Neste ponto, já era possível metrificar com alguma certeza o que seria sucesso, ou um sinal de que ainda era necessário trabalhar os conceitos que eu queria abordar.
Só aqui eu comecei a escrever algo que efetivamente seria aproveitado de forma direta no livro.
E assim, depois de muitos testes e iterações, tratei de montar a primeira versão, costurando todos estes conteúdos, que foram validados parte em conjunto, parte individualmente. Montei meu kanban e fui matando os problemas que precisava resolver, considerando cada capítulo uma item de backlog.
Com esta primeira versão do meu pequeno Frankenstein, e uma bela revisão feita pelo Marco Dubovski, entrei na Kindle Direct Publishing, montei uma capa e subi o livro.
Mas não acabou.
Antes de divulgá-lo, eu tinha certeza que haveria mais iterações, mais ajustes a fazer. Com isso, divulguei dentro da K21, e meus fantásticos pares me deram feedbacks valiosíssimos. A cada um deles, eu ajustava algo e subia uma nova versão, produzindo um novo arquivo a cada 4h, aproximadamente. Foi um fim de semana agitado.
E agora? O livro está pronto?
Na semana de lançamento, o livro se tornou best seller da categoria de gestão de projetos empresariais. Faço questão de mencionar isso não por orgulho, mas porque esta é uma métrica de vaidade que deve ser desconsiderada. Neste momento, estou acompanhando a taxa de compartilhamento do link para o livro, o aumento de visitas ao meu perfil no linkedin, além do óbvio: as taxas de venda e de leitura do livro na Amazon.
Espero que este livro nunca fique “pronto”. Um produto só acaba quando deixa de ser necessário para seu consumidor. Com isso em mente, continuo validando hipóteses, e sempre que eu descobrir algo a melhorar nele, sempre que eu receber um feedback que me faça acreditar que eu posso resolver melhor o problema, ele será mudado.
Quer ver como ficou? Clica aqui.
