Product Deck é uma “carta” ou um Canvas em uma página, de preferência, para agupar todas as informações úteis sobre um produto para qualquer um que precise entender de forma rápida: o que faz, não faz, quem faz, como é estruturado, e demais ações que ajudem a tomar decisões e avaliar contextos.
O Product Deck nasceu durante o Deploy First Development e foi inspirado pelo Report A3 que a Toyota resolvia problemas, criava planos e tinha as atividades realizadas enquanto revolucionava a indústria com Problem-solvers pensantes.
Product Deck simplificado
A estrutura mais simples que voce pode encontrar neste One-Page Template é uma versão que pode e dever ser customizada para o seu contexto.
Product Vision
A idéia do primeiro bloco é utilizar um template que defina exatamente o que o produto entrega e pra quem, aqui gostamos do formato do Product Vision do livro Crossing the Chasm, comum para quem realiza uma Lean Inception.
Assim ajudamos a manter o foco da equipe e de todos os participantes naquilo que produto deve entregar como resultado, sem distrações ou elocubrações que não venham de mudanças estratégicas bem direcionadas e de forma diligente.
Serviços do Produto
Já acompanhamos modelos que a seção seguinte era do time do produto, mas vir com os serviços principais que o produto entrega ajuda a complementar o Product Vision.
Duas colunas são importantes neste modelo além do titulo do serviço: um número de confiabilidade do serviço, mais importante quando ele está em produção; e o Lead-time quando ele está em desenvolvimento ou evolução com modificações frequentes.
Quando o serviço extrapola o produto, merece um Service Deck, porque terá mais um conjunto de informações relevantes além das fronteiras do Produck Deck.
Time do Produto
É importante separar a própria equipe que entrega e gerencia dos Stakeholders e demais participantes das decisões de um produto.
Informações variam, o ideal que visivelmente são as necessárias para ajudar no acionamento dos membros, em cenários que o time não é responsável por alguns ciclos, pode colocar pessoas de fora na listagem que realizam as ações sobre o produto.
Arquitetura de execução do Produto
Está uma seção obrigatória e importante ajuda o time a manter o entendimento sobre como ele é na verdade em relação aos riscos sobre suas dependências, o foco é mapear as relações entre aplicações, componentes (como DB, cache, etc) e serviços (sejam internos ou externos).
Para um novo produto que ainda não está em produção, ajuda a acompanhar e manter o time confortável que todos concordam com o desenho e os riscos são conscientes.
Claro que para pessoas sem conhecimento profundo sobre infraestrutura e peças de aplicações, o desenho pode parecer inútil ou desnecessário, mas o importante é garantir que ninguém esqueça ou discorde de uma parte, no Premortem de uma ProdOps, sempre trazemos para a reflexão.
Para produtos já em produção, além do benefício anterior, ajuda a verificar se a observabilidade acompanha o produto, toda mudança é acompanhada pela revisão da monitoria em cada nó no grafo (afinal o desenho não passa disso para esse caso)
Matriz de Confiabilidade
Matriz de Confiabilidade é uma evolução sobre a Matriz de resiliência, conceito amplamente consolidado e divulgado pelo Shopify.
Com o desenho da arquitetura de execução, fica relativamente fácil desenhar uma matriz, passo seguinte é transformar em Dashboard e linkar no Product Deck.
Com a Matriz criada em Dashboard de monitoria, ajuda a começar a construir um modelo inteligente de acionamento, deixo a referência do excelente serviço SaaS da Elven.works chamado One Platform (1P) que entega uma Matriz de Confiabilidade (BTW, além do Bruno Pereira ser sócio da Elven e parceiro da Produto Reativa, foi ele quem nos apresentou o conceito no passado).
Product Analytics
Informações sobre o resultado do produto com números de negócio da empresa relacionada com os serviços e a Dashboard de Confiabilidade para o time acompanhar as ações sobre o seu trabalho e melhorar o engajamento
Stakeholders
Na cultura de produtos não existem “clientes internos”, esse entendimento é trazido do modelo antigo de projeto e sustentação em TI. Quem é responsável por gestão e evolução que impacta no Roadmap e operação é Stakeholder.
Em alguns cenários que o time de produto não é multidisciplinar e não controla todo o ciclo de vida, essa lista se torna ainda mais importante.
Product Deck Expandido
A idéia deste artefato é ajudar a materializar a Tracking List em um index visual criando um ambiente informativo para consulta rápida, mais informações relevantes para a boa gestão são necessárias, expanda o documento a partir daqui para ajudar o time.
Em próximos artigos vamos explorar modelos mais completos em situações mais complexas.
Deixe um comentário