Garanti que o que saía do Discovery sobreviveria ao prazo, ao orçamento e à realidade física do armazém. Não fiquei só desenhando telas.
Nome do produto e do cliente alterados por acordo de confidencialidade. Detalhes reais disponíveis em entrevista.
Minha atuação nessa frente
- Discovery com stakeholders e usuários (entrevistas qualitativas)
- Mapeamento de personas (operador, gestor de armazém)
- Definição de 3 entregas iniciais do produto
- Gestão de backlog, épicos e User Stories no Jira
Risco identificado no Discovery. Mitigado antes de custar caro.
- POC entregue e validada, mitigando o maior risco do projeto: o desalinhamento entre o sistema digital e a realidade física do armazém
- Três entregas centrais desenhadas e estruturadas dentro do prazo de 4 semanas por sprint, sem ruptura de escopo
- Design system entregue garantindo consistência entre WMS e aplicativo móvel de operadores
- A base conceitual desenvolvida deu origem a um produto hoje comercializado ativamente no mercado de logística e RFID
O ArgoTrack foi entregue como prova de conceito, testado em ambiente controlado de desenvolvimento — não cheguei a acompanhar sua evolução até o lançamento comercial. Ainda assim, a arquitetura de produto que ajudei a conceber — do mapa de armazém em grid à integração RFID com WMS e ERP — segue sendo, hoje, a espinha dorsal de uma solução real ativa no mercado.
Conceber um WMS do zero — com prazo fechado e o maior risco escondido fora da tela.
ArgoTrack nasceu para resolver um dos maiores gargalos da logística de e-commerce: a falta de visibilidade sobre onde as mercadorias estão, como são movimentadas e onde se perdem no caminho. A proposta era ambiciosa — um WMS (Warehouse Management System) integrado a um aplicativo móvel para operadores, usando RFID para rastrear cada movimentação em tempo real, de sensores espalhados pelo armazém a leitores embarcados em empilhadeiras.
O prazo era rígido: 4 semanas de escopo fechado, por sprint. E o maior risco do projeto não estava na tecnologia — estava na tradução entre o mundo físico do armazém e o sistema digital. Grandes lotes entravam no sistema como unidades únicas, mas eram divididos em múltiplos destinos no processo físico real. Essa desconexão, se não resolvida no Discovery, geraria retrabalho caro depois que o desenvolvimento já tivesse começado.
Conduzi entrevistas com especialistas e operadores para mapear um risco que ninguém tinha nomeado ainda.
Como Product Owner e UX Lead, liderei um time enxuto — UX, UI, engenharia e operação — e conduzi o processo de Discovery pessoalmente: entrevistas qualitativas com empresários do setor, gestores de logística e operadores de armazém, mapeando personas como o operador de empilhadeira e o gestor de armazém. Limitações contratuais impediam pesquisa presencial no armazém, então extraí os aprendizados essenciais através de entrevistas direcionadas e profundas.
A partir disso, defini três entregas iniciais para guiar o backlog: entrada de mercadorias via registro de nota fiscal, armazenamento e controle de estoque, e localização e retirada para expedição. Geri o backlog inteiro no Jira, escrevi as User Stories, e mantive rastreabilidade completa de cada decisão até o desenvolvimento. Gosto particularmente desse tipo de projeto por isso: a parte estratégica de definir prioridade e a parte prática de desenhar o fluxo nunca estiveram separadas para mim — uma alimentava a outra o tempo todo.
Minha atuação nessa frente
- Discovery com stakeholders e usuários (entrevistas qualitativas)
- Mapeamento de personas (operador, gestor de armazém)
- Definição de 3 entregas iniciais do produto
- Gestão de backlog, épicos e User Stories no Jira
Decidir o que construir e desenhar como construir, na mesma semana.
A interface mais desafiadora do projeto foi o mapa do armazém em grid — cada metro quadrado representado digitalmente, incluindo áreas inviáveis como colunas e passagens. Como PO, eu sabia que essa decisão tinha peso de produto: definia se o sistema seria flexível o suficiente para atender clientes com layouts de armazém completamente diferentes. Como UX Lead, eu sabia que precisava ser usável por quem nunca tinha usado um mapa digital de estoque na vida.
Essa dupla camada de decisão — o que o produto precisa suportar, e como alguém vai operar isso de verdade — é o que mais me atrai nesse tipo de trabalho. Desenhei todas as interfaces pensando no contexto real de uso: botões grandes, dados legíveis, feedback imediato. Os protótipos evoluíram de wireframes para alta fidelidade, sustentados por um design system que garantiu consistência entre o WMS (desktop, para gestores) e o aplicativo móvel (para operadores).
O cliente nunca tinha trabalhado com protótipo. Eu precisei ensinar o processo, não só executá-lo.
Atuei como Product Owner e líder de design de uma equipe enxuta — UX, UI, QA, engenharia e produto — respondendo diretamente pelo contato com stakeholders, definição de épicos, organização de sprints e alinhamento de time. A priorização do backlog seguiu o fluxo básico da operação logística, dentro da limitação real de contrato, e ainda assim sustentei entregas funcionais a cada ciclo.
Houve momentos de mediação e educação genuína com o cliente, que nunca havia trabalhado com protótipos antes. Para acelerar o entendimento e reduzir fricção no desenvolvimento, produzi vídeos explicativos detalhando cada fluxo — uma forma de garantir que decisões de produto fossem compreendidas por quem não tinha vocabulário técnico para interpretar uma tela sozinha.
Aprendizado / Reflexão
“Esse projeto me ensinou que a maior contribuição de um Product Owner não é desenhar a tela certa mas traduzir uma operação física complexa em um sistema que faz sentido para quem nunca trabalhou com tecnologia antes.”
Doug Calebe
Equilibrar estratégia de negócio, usabilidade e tecnologia sob restrição real de prazo e contrato — essa foi a disciplina que esse projeto exigiu, e que carrego para qualquer produto complexo desde então.