05Produto digital · MT Labs

Deu Rhetorno

Transformar uma frustração recorrente em um produto colaborativo.

O Deu Rhetorno nasceu de uma pergunta simples: por que candidatos precisam acompanhar sozinhos processos seletivos que nunca respondem?

Contexto

MT Labs

Função

Product Manager

Natureza

Produto gratuito e colaborativo

O que é

O Deu Rhetorno é um produto digital gratuito e colaborativo para candidatos registrarem suas candidaturas em diferentes plataformas e relatarem quando empresas ou processos seletivos não dão retorno.

01

O problema

A experiência de candidatura é fragmentada.

O candidato se candidata em vários lugares, perde o controle do que enviou, não sabe em que etapa está e frequentemente fica sem qualquer retorno.

A informação sobre o processo existe, mas fica espalhada entre plataformas, e-mails e conversas — e nunca volta para quem está do outro lado.

02

A hipótese

Uma frustração individual pode virar informação coletiva.

A ideia foi transformar essa frustração individual em uma base colaborativa de informação: registrar candidaturas, organizar processos e tornar visível quando existe falta de retorno.

Se cada candidato registra a própria experiência, o conjunto dessas experiências passa a orientar as decisões de quem está se candidatando agora.

03

Discovery

O produto foi pensado antes de virar interface.

DefiniçãoDefinição do problema a ser resolvido.
PremissaEntendimento do comportamento do candidato ao longo de uma candidatura.
PremissaIdentificação das principais dores do processo.
DecisãoDefinição do que realmente precisava existir no MVP.
HipóteseHipóteses sobre o comportamento de quem procura emprego.
DecisãoPriorização das funcionalidades.
DecisãoDesenho dos fluxos principais.

Nada aqui veio de pesquisa formal com usuários. São definições, premissas e decisões de produto tomadas na concepção do projeto.

04

MVP e evolução

Começar simples e evoluir.

01

Problema

Uma dor clara e recorrente como ponto de partida.

02

MVP

A primeira versão com o mínimo necessário para registrar e relatar.

03

Validação / evolução

Ajustes no fluxo e no que realmente precisava existir.

04

Estrutura de dados

Saída do armazenamento local para uma base compartilhada.

05

Publicação

Produto no ar, com domínio próprio.

06

Próximos passos

Evolução contínua a partir do uso real.

A primeira versão trabalhava com armazenamento local, no próprio navegador (localStorage).

Depois, o projeto evoluiu para uma arquitetura conectada a GitHub, Supabase e Vercel, com domínio próprio.

A mudança técnica foi consequência de uma mudança de produto: para a informação ser colaborativa, ela precisava deixar de viver apenas no dispositivo de cada pessoa.

05

Como foi construído

Produto, UX, dados e interface evoluindo juntos.

O projeto foi desenvolvido no Lovable, de forma iterativa.

Não houve uma fase de especificação seguida de uma fase de construção: produto, experiência, estrutura de dados, interface e publicação avançaram na mesma linha do tempo.

Cada iteração servia para responder uma pergunta de produto e não apenas para adicionar tela.

06

Fluxos

O que o produto faz.

  1. 01

    Registrar candidatura

    Entrada rápida, com o mínimo de fricção possível.

  2. 02

    Acompanhar processos

    Visão do que foi enviado e em que ponto está.

  3. 03

    Organizar candidaturas

    Informação dispersa transformada em histórico.

  4. 04

    Sinalizar falta de retorno

    O silêncio da empresa vira um dado registrável.

  5. 05

    Usar a informação coletiva

    O que a comunidade relata ajuda outros candidatos a decidir.

Telas do produto

Por dentro do Deu Rhetorno

Capturas reais do produto no ar, em diferentes momentos da experiência.

Tela inicial
Registrar candidatura
Retorno e falta de retorno
Por que contribuir

07

Decisões de produto

O que ficou de fora também é decisão.

01

Começar pelo problema mais frequente e não por excesso de funcionalidades.

02

Reduzir ao máximo a fricção de registro.

03

Transformar informação dispersa em histórico organizado.

04

Pensar a colaboração como parte do produto, não como recurso secundário.

08

O que eu aprendi

Construir produto também é decidir o que NÃO construir.

O Deu Rhetorno reforçou a importância de transformar uma dor clara em um produto simples antes de tentar resolver tudo.

Cada funcionalidade a mais na primeira versão seria uma forma de adiar a resposta da única pergunta que importava: isso resolve o problema de quem está se candidatando?

Um produto simples que resolve uma dor real vale mais do que um produto completo que resolve uma dor imaginada.
Próximo projetoDe Olho no Mandato

Vamos construir
alguma coisa?

Estou aberto a conversas sobre posições de Product Manager, produtos digitais e projetos que precisem de alguém que já construiu negócio, time e produto.
Falar comigo