DIBB — um framework de alinhamento entre design e negócio
Destrave a fase intermediária do discovery com o PM e gestores.
Sabe quando você está em um discovery e parece que existe um loop infinito de discussões, sem contar os OKRs e outras dúvidas que o time de produto/negócio não conseguem ajudar?
Eu encontrei o DIBB que ajuda a dar um ar de “acabativas” e alinhamento no momento intermediário, onde as entrevistas e mapeamento de cenário já foram feitos e chega o momento que você pergunta para o time de negócio ou estratégia:
Qual desses pontos de valor para o usuário vamos priorizar ou faz mais sentido para o momento do produto?
Particularmente, demorei um pouco para encontrar uma utilidade no contexto ágil durante o processo de discovery para utilizar essa metodologia. Parte porque é mais comum falarmos de OKRs, e, outro motivo, é que geralmente, o time de negócio já possui diretrizes sólidas sobre quais os itens do roadmap precisam da solução de um designer.
⠀⠀
⠀⠀
O que é o DIBB
É um modelo de alinhamento entre discovery e estratégia, criado no Spotify e difundido pelo Henrik Kniberg — ex-Agile Coach na Spotify, hoje criador do Crisp.se.
Nesse framework, descrito como “um framework de argumento”, as diretrizes de negócio estão presentes e muito próximos com os objetivos da pesquisa, fornecendo uma ferramenta para a área de negócios (PM e gestores) tomarem decisões quando existir um impasse quanto a prioridade ou importância de determinadas features que foram validadas no discovery.
DIBB é o acrônimo para Data (dados), Insights (ideias), Beliefs (crenças)e Bets (apostas). Isso é disposto em um quadro, onde cada coluna agrupa as informações compartilhadas (assim como um Kaban, mas sem algumas diretrizes dessa ferramenta).
- Data: os dados conhecidos sobre o tema até o momento. Aqui vêm a saída do discovery, dados de negócio e mercado. Também pode vir de uma fonte de monitoramento interno (como churn, CAC, LTV, etc);
⠀⠀ - Insights: Ideias geradas a partir das hipóteses, dados, avaliação de similares. Enfim, aqui é um passo similar ao brainstorming, porém é guiado por dados direcionadores dessas ideias, não tão livre quanto o brainstorming já conhecido de inovação e design thinking;
⠀⠀ - Beliefs: Quais são as crenças? O que as pessoas envolvidas na tomada de decisão acreditam ser a coisa que importa investir? Qual seria um passo importante para o projeto? Respondendo essas perguntas, já temos a coluna de crenças respondida. Aqui também pode entrar a missão e visão da empresa/projeto;
⠀⠀ - Bets: Essa coluna é a “matadora”, pois aqui a gestão vai apostar suas fichas. Existe uma bifurcação aqui, mas parte-se do princípio que as apostas já estão direcionadas pela estratégia de negócio da empresa.
Sobre essa parte das apostas, é importante observar essa ramificação. No mundo real temos níveis de entendimento/desejos, sendo complementares (ou deveriam). Por isso é importante identificar, por exemplo: quais apostas da empresa, do time de produto, do time de estratégia, dos investidores, etc.
Além disso, para cada nível desse de apostas, é importante mapear uma cronologia e priorização dessas apostas. Para isso, pergunta-se: O que deveria ser feito agora? e depois? e depois disso, a médio e longo prazo (later)?
Uma das coisas que motivaram o questionamento e criação do framework é justamente aquelas perguntas que surgem quando olhamos para o quadro de prioridades e perguntamos: Tá, mas por que isso é prioridade? Assim temos uma visibilidade melhor do que guiou o projeto.
Como funciona?
O DIBB não é para ser construído em uma etapa X, mas sim durante todo o projeto.
Principalmente a identificação de qual é a estratégia e expectativas da empresa, além de um alinhamento entre os setores stakeholder.
Então, primeiramente é importante ter esse mapeamento em mãos e que o discovery consiga trazer informações acerca dessas apostas.
Explicações e exemplo
Pela leitura do quadro, iniciamos preenchendo os dados. Isso significa ser necessário trazer as informações já consolidadas. Vindo de diversas áreas, incluindo comercial, benchmarking de negócio (product manager), discovery (product designer), retenção (CS). O product designer responsável por consolidar essas informações, geralmente trará esses dados consolidados de uma matriz CSD anteriormente criada pelas etapas de pesquisa.
Seguindo para o processo de ideação, os insights são uma compilação de ideias geradas nas sessões de brainstorming, porém direcionadas pelos dados. Essa fase de insights pode trazer também algum recorte de benchmarking, exemplificando ideias e mostrando também algum protótipo — caso tenha realizado alguma sessão de crazy 8 ou co-criação.
Sobre as crenças, aqui entra uma questão de feeling e análise dos stakeholders. Se tivermos direcionadores de tecnologia, experiências anteriores dos envolvidos em decisão de negócio ou tendências de mercado, isso tudo deve vir para essa coluna de crenças.
O significado raiz dessa coluna e o diferencial para a coluna de apostas é que aqui os valores dos participantes são expostos. Coisas como dinamismo, agilidade, simplicidade, diminuição de custos, geração de oportunidade de vendas e outros são colocados aqui.
Também pode servir para retroalimentar o discovery, pois aqui também existem hipóteses ainda não validadas para provocar uma busca de dados.
Conclusão
Esse modelo de mapeamento pode ser utilizado em substituição ou em paralelo aos OKRs, pois precisa estar alinhado com as estratégias de negócio. Em adendo as colunas iniciais, a área de apostas contempla aquelas apostas do time e pode substituir as promessas de moon / roof shot.
Moon Shot (tiro na lua): Objetivo muito alto, muito difícil de alcançar. Ex.: Construir uma casa de 2 dias, usando tijolo maciço.
Roof shot (tiro no teto): Objetivo mais palpável, depende de um esforço razoável, mas factível com o cenário atual. Ex.: prototipar 1 fluxo do usuário por semana para o ERP (sistema de gestão).
Não é largamente utilizado e às vezes um tanto difícil de dar manutenção, pois precisa de uma certa dedicação e rigor no acompanhamento para que esteja realmente espelhando a estratégia do projeto/produto/empresa. Por isso é importante que seja colaborativo e reúna participantes de diversas áreas, mostrando uma integração e evolução do trabalho.
P.S.: esse texto não é uma tradução literal do framework, mas sim uma interpretação e considerações por já ter aplicado.
