Por onde começar um produto de dados?

Case: Data product discovery no P&D

Caetano
gb.tech
Published in
10 min readAug 2, 2024

--

Data product discovery no P&D.

Você é um Product Manager ou uma Liderança e está com a missão de desenvolver um produto de dados que utiliza Inteligência Artificial, mas não sabe por onde começar? Não se preocupe, este é um desafio comum no universo dos data products.

Por conta disso, estruturei este case de data product discovery, realizado no Grupo Boticário, para te fornecer uma referência prática sobre como dar os primeiros passos em um produto de dados.

Neste artigo, compartilho a experiência de conduzir o discovery upstream do primeiro produto de dados com IA para a área de P&D. Desde o entendimento do contexto e das oportunidades até a abordagem metodológica e os desafios enfrentados, vou explorar o caminho percorrido para responder à pergunta crucial: Por onde começar a desenvolver um produto de dados/AI?

O artigo está dividido da seguinte forma:

  1. Contexto da área de P&D do Grupo Boticário
  2. AI Data Product: Oportunidades com IA na formulação
  3. Abordagem Data Product Discovery
  4. Do JTBD à QTBA: Mapeando as jornadas de decisão
  5. Workshop de hipóteses e desenho de Casos de uso
  6. Priorização dos Data use cases
  7. Conclusão

Contexto da área de P&D do Grupo Boticário

Hall de entrada do centro de P&D do GB.
Hall de entrada do centro de P&D do GB.

A área de Pesquisa e Desenvolvimento é responsável por desenvolver os produtos que chegam nas mãos dos nossos consumidores. Um dos principais processos realizados no P&D é a formulação de produtos de quatro principais categorias:

  • Cabelo e Banho
  • Facial, Infantil, Solar e Corporal
  • Perfumaria, Datas e Acessórios
  • Maquiagem

No P&D, os pesquisadores recebem e analisam o briefing dos produtos a serem desenvolvidos, identificando os requisitos específicos a serem atendidos, como hidratação por 48 horas, efeito anti-idade, toque seco, entre outros.

Com base nesse entendimento, eles estudam a literatura científica mais atual sobre cosméticos e avaliam diversas matérias-primas (MPs), considerando os ativos e suas concentrações necessárias para obter os efeitos desejados. Na bancada do laboratório, os ingredientes são manipulados até se encontrar uma fórmula promissora.

O P&D é o local onde são desenvolvidas fórmulas de produtos icônicos como o novo shampoo da linha Siáge by Eudora, os produtos da linha Niina Secrets e novas edições do perfume Malbec.

AI Data Product: Oportunidades IA na formulação

Formuladoras do GB olham para um Becker.
Formuladoras do GB olham para um Becker.

Para desenvolver seu trabalho, os formuladores do P&D precisam considerar diversos contextos de dados, como custos de matérias primas, ativos e funções das MPs, questões regulatórias da Anvisa, grau de sustentabilidade das MPs, entre vários outros.

Por essa razão, reconhecendo as inúmeras variáveis necessárias ao longo da jornada de formulação, foi identificado o potencial da IA para apoiar os formuladores na tarefa de cruzar todas essas variáveis e desenvolver uma fórmula ideal que atenda ao briefing.

Em 2023, Réris Lima, especialista em dados da área de Gestão e Performance do P&D, mapeou e realizou a valoração do potencial de um produto de dados com IA em várias jornadas do P&D.

Com base no mapeamento de oportunidades de negócio e do potencial Data Product, meu desafio como Data Product Manager (DPM) foi mapear o processo decisório da jornada de formulação; Para, em seguida, cruzar esse entendimento com a estratégia do ecossistema do Grupo Boticário e determinar em quais etapas deveríamos entregar valor primeiro através do produto de dados.

A pergunta que eu tive como objetivo responder com meu discovery foi:

“Por onde devemos começar o desenvolvimento do produto de dados com IA dentro da jornada de formulação?”

Abordagem Data Product Discovery

Representação visual da abordagem Data Product Discovery.
Representação visual da abordagem Data Product Discovery.

Para responder essa pergunta, utilizei como base a abordagem Data Product Discovery (DPD) desenvolvida pela Luma Corrêa (minha atual líder no GB) e Carolina Vega.

A abordagem tem como objetivo apoiar data product managers a:

  • Mapear contextos de negócio e tecnológico
  • Rastrear decisões críticas e analisar os processos de decisão
  • Criar hipóteses em data e análises
  • Desenhar casos de usos e construir roadmap

Com a abordagem em vista, adaptei a metodologia dedicando um tempo para mapear o negócio e o contexto do P&D, seguido por um período de entrevistas com formuladores das quatro categorias. Converti meu entendimento em uma jornada de decisão e realizei um workshop (WS) presencial para validar essas jornadas e co-construir hipóteses e casos de uso (data user cases) junto com os formuladores e lideranças.

Do JTBD à QTBA: Jornadas de decisão

Pesquisadora do Grupo Boticário desenvolvendo uma fórmula.
Pesquisadora do Grupo Boticário desenvolvendo uma fórmula.

Os “jobs to be done” (JTBD) são amplamente reconhecidos no contexto de produtos digitais. Para Clayton Christensen, JBTD é uma abordagem que ajuda a compreender o que as pessoas realmente desejam alcançar através de um produto ou serviço. Segundo essa abordagem, quando alguém adquire um item ou serviço, a intenção é obter uma experiência específica ou resolver um problema, e não apenas possuir o produto em si.

Enquanto isso, no contexto de produtos de dados, existe outro conceito relevante: o de “questions to be answered” (QTBA) proposto pelo DPD. Produtos de dados têm a função de agilizar ou melhorar a qualidade de decisões, atendendo às perguntas que os usuários fazem, consciente ou inconscientemente. A compreensão do processo decisório do usuário e a identificação de quais dados são relevantes para essa decisão são fundamentais para o desenvolvimento de um data product.

Essencialmente, enquanto os JTBDs focam nas tarefas que os usuários “querem” realizar, as QTBAs se concentram nas perguntas que precisam ser respondidas para viabilizar decisões estratégicas. Esta abordagem permite que os produtos de dados sejam projetados de maneira a fornecer insights específicos e valiosos, otimizando a tomada de decisão dos usuários e criando experiências inteligentes.

Por conta disso, com base na abordagem Data Product Discovery, meu escopo foi realizar entrevistas e desenhar a jornada decisória da formulação em três camadas:

1. PROCESSO

Primeiro, mapeei as etapas base do processo de formulação e as decisões tomadas ao longo da jornada, transformando um processo complexo em uma sequência linear.

2. DORES

Em seguida, identifiquei as dores associadas a cada etapa do processo. Cada formulador tinha uma visão diferente sobre a intensidade dessas dores, então criei uma escala de dores conectando-as ao contexto do negócio e à jornada de formulação:

  • Dor leve: Não compromete o processo, mas é desejável que seja resolvida.
  • Dor moderada: Atrasa o processo, porém não apresenta riscos significativos de erros críticos.
  • Dor intensa: Atrasa significativamente o processo e aumenta o risco de erros críticos.

3. QUESTIONS TO BE ANSWRED (QTBAs)

Por fim, a parte mais interessante da abordagem DPD foi identificar quais perguntas precisam ser respondidas em cada etapa do processo para que uma decisão seja tomada. Busquei compreender as perguntas que os formuladores se fazem a cada etapa. Assim, pude entender como os dados podem agilizar ou melhorar a qualidade das decisões que respondem às QTBAs.

O mapeamento de QTBAs diferenciou minha perspectiva de discovery de um produto digital para um produto de dados. Com um entendimento profundo do que o formulador considera ao decidir, como ele pensa e quais perguntas se faz, mesmo que inconscientemente, estabeleci um insumo base para propor soluções através de dados.

Legenda das camadas da jornada de decisão.
Legenda das camadas da jornada de decisão.

Para proteger informações sensíveis do GB ao apresentar exemplos e resultados do processo, substituirei o contexto de formulação por um contexto de cozinha, onde o objetivo é cozinhar um bolo.

Representação fictícia da jornada.

Workshop de hipóteses e Data use cases

Pessoas trabalham dentro do centro de desenvolvimento de embalagens do Grupo Boticário.
Pessoas trabalham dentro do centro de desenvolvimento de embalagens do Grupo Boticário.

Ao começar a planejar o Workshop (WS), a primeira coisa que fiz foi selecionar os participantes.

Decidi incluir os seguintes perfis:

  • Produto: Group Product Manager (operações) e PM do P&D (Eu). Nosso papel foi facilitar o WS e apoiar os participantes na tomada de decisões para identificar casos de uso promissores.
  • Data Science: Manager, Squad Leader e Cientista de Dados. Eles ajudaram os formuladores a traduzir suas dores e QTBAs em soluções de IA, considerando a viabilidade e potencial complexidade do que estava sendo proposto.
  • Analytics Engineer: Manager e Analista de Domínio/Data P.O. Eles trouxeram uma visão sobre a disponibilidade dos dados, começaram a avaliar a viabilidade e apoiaram com soluções baseadas em engenharia analítica.
  • Formuladores: Lideranças e formuladores de cada uma das categorias. Foram protagonistas nas decisões ao longo do WS, trazendo o contexto da formulação.
  • Stakeholders P&D: Business Owner, liderança e analista de dados. Eles contribuíram com uma visão de negócio durante o WS.

Após a decisão de quem seriam os participantes, alinhei com a Business Owner do P&D a carga horária do WS. Tivemos duas manhãs das 9h às 12h totalizando 6h de Workshop.

Dividi o fluxo da dinâmica da seguinte forma:

  • Dia 01 | Validação das jornadas de formulação
  • Dia 02 | Discovery de solução

Antes do dia do WS, alinhei com a liderança a importância que os times de Analytics Engineer e Data Science fossem embarcados nas jornadas que eu havia mapeado. Isso permitiria que eles tivessem mais contexto sobre a formulação e pudessem contribuir de maneira eficiente durante o WS.

Para isso, conduzi dois dias de reuniões remotas para pré-levantamento de hipóteses e casos de uso. Nessas agendas, apresentei as jornadas ao time, e juntos ideamos algumas possibilidades.

Dessa forma, além termos ficado na mesma página em relação à compreensão do usuário, já tínhamos algumas propostas de produto em mãos, permitindo que fôssemos ainda mais propositivos durante o workshop presencial.

Planilha de fluxo da dinâmica do Workshop.

Dia 01 | Validação das jornadas de formulação

O objetivo do dia foi garantir que as jornadas mapeadas previamente durante as entrevistas representassem bem as experiências dos formuladores.

| APRESENTAÇÃO E REVISÃO DAS JORNADAS |

  • Apresentação das jornadas: Durante a apresentação, expliquei detalhadamente cada ponto das jornadas previamente mapeadas.
  • Anotações em post-its: Os formuladores fizeram anotações em post-its enquanto eu explicava as jornadas. Esse método permitiu uma coleta rápida e eficiente de feedbacks e sugestões.
  • Colagem nas cartolinas: Após a explicação, os formuladores levantaram-se e colaram suas anotações nas cartolinas impressas com as jornadas na parede, encaixando cada post-it na etapa correspondente. Isso permitiu visualizarmos claramente as contribuições de cada participante e facilitou a identificação de pontos de melhoria.
Pessoa escreve em uma cartolina coberta de post-its.
Pessoa escreve em uma cartolina coberta de post-its.

Dia 02 | Discovery de solução

O objetivo do segundo dia foi materializar hipóteses de solução e casos de uso para produtos de dados que atendam às dores e às QTBAs levantadas na jornada de formulação. Para alcançar esse objetivo, trabalhamos em grupos, onde os formuladores inicialmente construíram, com o apoio dos times de dados, suas hipóteses e casos de uso.

| DINÂMICAS DE TRABALHO EM GRUPO |

  • Construção de Hipóteses e Casos de Uso: Os formuladores, auxiliados pelos times de dados, começaram a elaborar hipóteses e casos de uso baseados nas dores e QTBAs identificadas anteriormente.
  • Validação e Ajuste: Em seguida, eles receberam as hipóteses e casos de uso previamente levantados pelo time de dados em nossa pré-rodada para validar ou ajustar conforme necessário. Essa etapa garantiu que as propostas fossem refinadas e estivessem alinhadas com o processo decisório da formulação.

| FERRAMENTAS UTILIZADAS |

Esse trabalho foi facilitado pelo uso de templates previamente impressos em papel, o que ajudou na estruturação e padronização das ideias.

  • Template de Hipóteses de Solução

Acreditamos que: [a solução é assim e pode melhorar o processo assado.]
Saberemos que estamos certos: [se garantirmos a otimização processual.]

  • Template de Data User Case

Dado que: [usuário está em determinado contexto.]
Quando: [precisar realizar determinada ação.]
Então: [o sistema responderá da seguinte forma.]
Qual o tipo de dado?
Qual a fonte do dado?
Qual informação será monitorada?
Quais são os insights e benefícios acionáveis do caso?

Representação fictícia caso de uso.
Representação fictícia caso de uso.

Priorização data use cases

Pessoas olham para uma tela dentro do centro de P&D.
Pessoas olham para uma tela dentro do centro de P&D.

Os casos de uso foram essenciais para transformar as jornadas de decisão, utilizando dados para viabilizar melhores decisões ou tornar decisões mais ágeis para atacar as dores e as QTBAs. Essa abordagem colaborativa garantiu que as soluções propostas fossem viáveis e alinhadas com as necessidades reais dos formuladores.

Após o WS, dedicamos um período para a análise detalhada dos sete casos de uso co-construídos. Cada caso foi avaliado sob três perspectivas principais: impacto no negócio, esforço necessário em engenharia analítica (AE) e complexidade envolvida em data science (DS).

Durante essa fase, consideramos a disponibilidade e prontidão dos dados, os potenciais modelos de DS para viabilizar os casos e realizei uma valoração inicial do impacto esperado em colaboração com os formuladores.

Além disso, foi realizado um profundo discovery de dados conduzido pelo Data Product Owner para identificar de forma mais assertiva a origem dos dados mapeados em cada caso (Transações SAP, CRM, Módulos ERP, planilhas, etc).

O alinhamento e a colaboração entre as disciplinas de DS, AE e Produto nos permitiu chegar a uma priorização clara, utilizando uma matriz que combinava esforço em engenharia x impacto no negócio / usuário x complexidade em data science. Com essa matriz, obtivemos uma visão clara de quais casos deveriam ser priorizados.

Representação fictícia matriz de priorização.
Representação fictícia matriz de priorização.

Com os casos de uso priorizados, o próximo passo foi dividi-los em experimentos, desenhar um roadmap e organizar as esteiras de trabalho para AE e DS. Uma vez que todo o time de produto esteve embarcado no discovery desde o início foi possível realizar uma eficiente virada de chave do discovery para o delivery.

Conclusão

Pessoa mexe em computador e existem produtos do GB ao redor.
Pessoa mexe em computador e existem produtos do GB ao redor.

Através desta jornada de discovery, consegui conduzir uma abordagem estruturada e colaborativa para a especificação de um produto de dados com Inteligência Artificial no contexto de formulação.

Ao mapear detalhadamente as jornadas de decisão, identificar QTBAs críticas e levantar data use cases, pude construir uma base sólida junto com usuários e pares para definir requisitos de produto que atendem às necessidades reais dos formuladores.

A abordagem Data Product Discovery se mostrou, na minha experiência, um excelente caminho para responder à pergunta: por onde começar um produto de dados?

A jornada de desenvolvimento de um produtos de dados é contínua, e este é apenas o começo. Siga o Medium do GB.Tech para conferir novos artigos sobre data products!

--

--

Caetano
gb.tech

Data Product Manager | AI | Professor | Researcher