entrevista técnica APM Flashcards
(42 cards)
Me fala sobre um produto favorito e como você melhoraria ele
Um dos meus aplicativos favoritos no momento é o TickTick, uma ferramenta de produtividade que se destaca por oferecer uma experiência completa e bem executada. Já testei muitos apps que tentam ser all-in-one, mas acabam falhando ao tentar cobrir diversas funcionalidades sem realmente entregá-las com qualidade. Sempre busco ferramentas que me ajudem tanto nas tarefas profissionais quanto pessoais, já que, além do trabalho, estou constantemente estudando algo novo ou desenvolvendo hobbies. O TickTick é o único que consegue atender todas essas necessidades de forma eficiente, com uma interface simples, visualmente agradável e altamente funcional.
Principais funcionalidades e diferenciais do TickTick:
> Gestão de tarefas e listas: Criação de listas, sub-tarefas e categorização para melhor organização.
> Pomodoro integrado: Técnica de Pomodoro embutida no app para aumentar a produtividade e o foco.
> Calendário sincronizado: As tarefas agendadas aparecem diretamente no calendário, facilitando o planejamento visual.
> Colaboração: Possibilidade de compartilhar listas e trabalhar em equipe.
> Personalização: Temas e ícones customizáveis para tornar a experiência mais única.
> Multiplataforma: Sincronização em tempo real entre Android, iOS, Windows e Web.
> Gestão de hábitos e metas: Funcionalidade para rastrear hábitos e objetivos de longo prazo.
> Gamificação: Recompensas e conquistas para motivar os usuários a completarem suas tarefas.
> Matriz Eisenhower: Ajuda a priorizar tarefas com base na urgência e importância, otimizando a gestão do tempo.
Pra isso, a gente também precisaria analisar o público do app.
Ao analisar como os usuários utilizam o TickTick, percebi que há uma grande presença de estudantes — como alunos de medicina — que usam o app para gerenciar tanto suas responsabilidades acadêmicas quanto pessoais. Isso indica que o TickTick atende bem pessoas que precisam equilibrar múltiplas áreas da vida, sejam estudantes, profissionais ou qualquer um que busque mais organização no dia a dia.
O modelo de negócios do app é freemium, ou seja, a versão gratuita oferece acesso às funções essenciais, enquanto a versão premium, por assinatura anual, desbloqueia recursos avançados. Com isso, acredito que duas das métricas mais importantes para o sucesso do produto seja a taxa de conversão de usuários gratuitos para pagos, além da retenção dos usuários premium.
North Star Metric: Engajamento Diário para Impulsionar Retenção e Conversão
Para este exercício, acredito que a North Star Metric do TickTick poderia ser o aumento do Daily Active Users (DAU). O uso diário é um indicador essencial para garantir que os usuários continuem engajados, o que, consequentemente, impacta a retenção dos assinantes premium e a conversão de usuários gratuitos para a versão paga.
Ao focar na retenção, garantimos que os usuários não apenas utilizem o produto, mas continuem investindo nele a longo prazo, fortalecendo o modelo de negócio e impulsionando um crescimento sustentável para a empresa.
Sugestões de Melhorias no Produto
Como usuária do TickTick, vejo várias oportunidades de melhoria que poderiam aumentar ainda mais o engajamento:
> Integração com Google Agenda: Para sincronizar compromissos e tarefas em um só lugar.
Visão Kanban das tarefas: Permitiria visualizar o fluxo de trabalho de forma mais intuitiva.
Assistente planejador: Uma funcionalidade que reorganizasse automaticamente a agenda diária com base nos prazos, prioridades e subtarefas definidas. Embora essa feature tenha um alto nível de complexidade, poderia ser um grande diferencial para usuários avançados.
No entanto, para uma solução mais simples e focada na north star metric que foi pensada aqui para o nosso exercicio, eu acredito que lembretes estratégicos com uma linguagem mais próxima do usuário poderiam ser uma ótima adição. Algo similar ao que o Duolingo faz, mas com um tom menos ousado, reforçando a importância de concluir tarefas pendentes.
> Além disso, uma funcionalidade de progressão visual poderia aumentar a motivação do usuário, como mensagens do tipo:
“Você já completou 50% das suas tarefas mais importantes do dia!”
> Outra ideia seria criar uma experiência gamificada voltada para a construção de hábitos, algo que o TickTick ainda não explora totalmente. Ao incentivar o uso diário do app de forma estruturada, o produto se tornaria ainda mais essencial na rotina do usuário, fortalecendo a conversão e também retenção no longo prazo.
Fale sobre sua experiência anterior como Junior Product Manager e como você contribuiu para o sucesso do produto.
Atualmente, atuo como Product Owner em um WebApp para gestão de pacientes com doenças raras, que está em fase de desenvolvimento. Embora ainda não tenhamos realizado testes com usuários finais, estamos em uma fase beta, e minha contribuição foi essencial desde o início do Discovery.
Nosso desafio era claro: uma ONG que atende pacientes com uma doença rara tinha processos descentralizados, resultando na perda de dados cruciais. Esses dados são fundamentais tanto para mapear a doença no país quanto para auxiliar os pacientes em questões jurídicas, como a obtenção de medicamentos e benefícios – especialmente porque a doença ainda não é reconhecida pelo SUS.
No começo, meu papel foi muito mais estratégico e estrutural, e agora, na fase de desenvolvimento, venho atuando mais no dia a dia tático do produto. Algumas das minhas principais contribuições foram:
Discovery e definição do problema
> Estruturação do Discovery: Liderei todo o processo, com mentoria de uma PO mais experiente.
Desk research aprofundado: Antes das entrevistas, realizei um estudo detalhado sobre a doença, analisando artigos científicos, matérias e pesquisas acadêmicas para garantir um entendimento sólido.
> Entrevistas exploratórias com especialistas: Conversei com médicos para compreender a realidade clínica da doença e seus desafios.
> Entrevistas com usuários finais: Conduzi entrevistas com a equipe médica que usaria a aplicação, além de gestores e captadores de recursos da ONG, que dependem dos dados coletados.
> Construção de personas e jornada do usuário: Em parceria com UX, desenvolvi personas e mapeei toda a jornada dentro da aplicação, que hoje serve como base para o roadmap do produto.
Priorização e definição do MVP
Com os insights do Discovery, minha próxima missão foi transformar essas descobertas em um MVP viável, equilibrando as necessidades da ONG, a viabilidade técnica e a complexidade do desenvolvimento.
> Definição das funcionalidades essenciais: Junto ao time de tecnologia, identificamos quais features deveriam compor o primeiro release.
Refinamento do escopo: Trabalhei com os stakeholders para alinhar expectativas e garantir que o MVP atendesse às principais dores sem comprometer a entrega.
Criação e validação dos primeiros wireframes: Em parceria com UX/UI, validamos as principais telas com os usuários antes de avançar para o desenvolvimento.
Definição da arquitetura de dados: Como a aplicação lida com informações sensíveis, participei das discussões sobre a estruturação do banco de dados e segurança das informações.
Planejamento da entrega e início do desenvolvimento
Com o escopo fechado e as telas validadas, iniciamos o planejamento da primeira sprint. Meu foco foi garantir que a transição do Discovery para o Delivery fosse estruturada e eficiente.
> Criação do backlog do produto: Estruturei as user stories e critérios de aceitação, garantindo que os requisitos estavam claros para o time de desenvolvimento.
Roadmap e definição de milestones: Estabelecemos as primeiras entregas e criamos um roadmap realista, considerando as limitações do time e os desafios técnicos.
Facilitação do refinamento técnico: Trabalhei junto ao Tech Lead e DevOps para alinhar a arquitetura da aplicação e solucionar dúvidas antes do início do desenvolvimento.
Kickoff da primeira sprint: Organizamos um planejamento detalhado, priorizando a entrega de um fluxo inicial funcional para que pudéssemos começar os testes internos o quanto antes.
Agora, com o desenvolvimento em andamento, meu foco está em garantir que os ciclos de entrega sejam bem estruturados, acompanhando métricas de uso e feedbacks para futuras iterações.
Como você lida com mudanças de escopo durante o desenvolvimento de um produto?
Entendo que mudanças de escopo são naturais durante o desenvolvimento de um produto, especialmente em ambientes ágeis. Quando isso acontece, meu primeiro passo é entender a motivação por trás da mudança e como ela impacta os objetivos do produto. Por exemplo, em um projeto recente, durante o desenvolvimento do MVP de um webapp para uma ONG, surgiram novas exigências regulatórias que exigiam a inclusão de um módulo de consentimento de dados. Nessa situação, reavaliei o backlog com os stakeholders, priorizei a mudança com base em seu impacto crítico e ajustei o planejamento de entregas, mantendo a equipe e os stakeholders informados. Procurei redistribuir recursos e tarefas de forma a garantir que o MVP fosse entregue dentro do prazo, sem comprometer a qualidade ou a experiência do usuário. Acredito que a chave é manter uma comunicação clara e constante e sempre focar no valor agregado com a mudança, ajustando as prioridades conforme necessário.
Como você trabalha com equipes multidisciplinares para garantir a entrega de um produto de qualidade?
Minha experiência em agências, onde liderei times com designers, desenvolvedores e clientes, me ensinou a importância de uma comunicação clara e de objetivos compartilhados. No projeto da ONG, por exemplo, realizava reuniões diárias de alinhamento com UX e engenharia, usando o Miro para mapear jornadas e o Figma para validar protótipos. Além disso, criava documentações concisas (como user stories com critérios de aceitação bem definidos) para evitar ambiguidades. Um aprendizado valioso foi incluir o time técnico nas etapas iniciais do discovery: isso não só aumentou o engajamento, mas também trouxe insights sobre viabilidade que evitaram retrabalho.
Como você lida com feedback negativo dos usuários e como utiliza esse feedback para melhorar o produto?
Olha, recentemente, durante o teste beta do produto em que trabalho hoje, recebemos feedbacks críticos sobre o fluxo de cadastro de novos pacientes. Os usuários relataram que o formulário era muito longo, com alguns campos redundantes, e muitos mencionaram frustração por precisar preencher tantas informações.
Para lidar com isso, adotamos uma abordagem exploratória, voltando algumas etapas para entender melhor o problema. Primeiro, tranquilizamos os usuários, reforçando que a experiência deles era nossa prioridade e que revisaríamos o fluxo com cuidado, sem criar expectativas que não pudéssemos atender no MVP.
Em seguida, realizamos novas sessões de uso gravadas para observar os principais pontos de fricção. Uma descoberta interessante foi que mais da metade dos usuários gastava muito tempo revisando e voltando ao início do formulário. Além disso, 80% deles descia até o final da página antes de começar a preencher. Quando perguntamos o motivo, a resposta foi que eles queriam visualizar todas as perguntas antes de começar.
Com base nessas observações, categorizamos os problemas e criamos uma matriz de priorização com a ONG. Definimos dois pontos essenciais:
A experiência do usuário precisava ser mais clara, com melhor feedback visual e menos redundâncias.
Não poderíamos simplesmente remover campos, pois todas as informações eram essenciais para a ONG.
Diante disso, propusemos algumas soluções para melhorar o fluxo sem comprometer a coleta de dados:
Quebra do formulário em três etapas bem nomeadas: Dados gerais, histórico médico e rede de apoio (uma informação relevante para esse perfil de paciente). Isso permitiu que os usuários tivessem mais clareza sobre seu progresso e evitou a sensação de um formulário “interminável”.
Reformulação de perguntas para reduzir redundâncias: Por exemplo, em vez de dois campos separados — um perguntando “Você possui deficiência?” (Sim/Não) e outro solicitando detalhes apenas se a resposta fosse “Sim” — condensamos tudo em uma única pergunta opcional: “Você possui alguma deficiência? Se sim, descreva quais.” Isso reduziu a quantidade de campos e tornou a experiência mais fluida.
Após definir essas melhorias, validei com o time técnico para entender a viabilidade e possíveis impactos no backend. Trabalhei junto com UX para criar protótipos em alta fidelidade e conduzi novos testes com usuários. Os resultados foram significativos: o tempo médio para completar o formulário caiu de mais de 10 minutos para cerca de 6 minutos, além de um aumento na taxa de conclusão.
Esse processo mostrou como feedback negativo, quando tratado da maneira certa, pode se tornar um motor de melhoria contínua. Minha abordagem é sempre transformar essas críticas em insights acionáveis, equilibrando a experiência do usuário com as necessidades do negócio.
Que técnicas e ferramentas você utiliza para estruturar discovery?
Em relação ao discovery, até agora, minha experiência tem sido em processos mais tradicionais, como entrevistas com usuários, análise de dados e workshops de brainstorming para explorar as necessidades do usuário e priorizar as soluções. Eu tive a oportunidade de participar ativamente de algumas etapas de discovery, onde o foco foi em entender as dores do cliente e definir os problemas a serem resolvidos antes de avançar para as soluções.
No entanto, ao saber que sua equipe utiliza a metodologia Shape Up para o discovery, fiquei curiosa e fiz uma leitura aprofundada sobre ela, especialmente pelo livro do Basecamp. Eu entendi que ela foca em evitar longos ciclos de planejamento e nas pools de trabalho de 6 semanas, com entregáveis mais focados e viáveis. O que achei interessante na Shape Up é como ela ajuda a manter as equipes mais focadas e comprometidas, evitando a tentação de adicionar muitas features ou mudanças no escopo no meio do caminho. Vejo como um jeito bastante eficiente de estruturar o processo e garantir que o time consiga entregar valor de forma contínua.
Fale um pouco sobre você
Eu comecei minha carreira como jornalista, inicialmente trabalhando com conteúdo para revista impressa e, depois, migrei para o digital, onde fui me especializando em conteúdo para redes sociais. Cada nova etapa me trouxe desafios mais complexos, que me fizeram desenvolver uma abordagem estratégica sobre como as marcas se comunicam com seu público.
Quando comecei a trabalhar em agências e passei a colaborar diretamente com marcas, percebi que meu interesse estava mudando. Eu queria entender o negócio de maneira mais holística, como diferentes áreas se conectam, e como o marketing de conteúdo poderia ser mais estratégico. Fui me aprofundando em como os dados de mídia impactam o desafio de negócio dos clientes, e isso despertou uma curiosidade crescente sobre como poderia contribuir de maneira mais direta para as estratégias. Foi aí que minha curiosidade começou a me levar para uma nova direção, mas ainda sem saber exatamente qual.
Tive o privilégio de entrar em contato com profissionais de produto, que me diziam que meu perfil combinava com a área. Porém, eu ainda não entendia completamente o que significava ser Product Manager. A grande virada veio quando trabalhei em um projeto de produto, criando uma estratégia de listening e monitoramento de marca, focada em extrair insights para direcionar o desenvolvimento do produto. Foi nesse momento que percebi que esse era o caminho que eu queria seguir.
Ao chegar na Alemanha, decidi me dedicar completamente a essa transição de carreira. Passei a trabalhar como freelancer, comecei a aprender programação, e, embora tenha percebido rapidamente que essa não era minha praia, entendi que esse conhecimento técnico seria valioso para minha jornada no produto.
Desde então, estudei profundamente sobre o universo de produto: fiz cursos, li livros, ouvi podcasts e fui me especializando na interseção entre negócio, tecnologia e experiência do usuário. Cada vez mais, me vejo motivada por esse papel de conexão entre esses três pilares, traduzindo as necessidades dos usuários em soluções viáveis e inovadoras.
Além disso, sou uma pessoa caseira, adoro ler ficção e histórias de mistério, sou uma entusiasta de yoga, tenho três gatos e sou casada há três anos. Gosto muito de viajar, conhecer novos lugares e explorar restaurantes novos ao redor do mundo
Quais são seus principais objetivos como Junior Product Manager e como você planeja alcançá-los?
Meus objetivos imediatos são:
Aprofundar habilidades em estratégia de produto: Aplicar frameworks como JTBD e Opportunity Solution Trees, que estou estudando na PM3.
Melhorar a tomada de decisão técnica: Colaborar mais de perto com engenharia, participando de reuniões de arquitetura (como fiz no projeto de microserviços).
Impactar métricas de negócio: Contribuir para indicadores como retenção e receita, conectando entregas de produto a resultados tangíveis.
Para isso, pretendo buscar mentoria interna, dedicar 2h/semana a cursos específicos (ex: analytics avançado) e documentar learnings após cada sprint
Quais métricas você acompanha no produto que trabalha atualmente?
No produto que estamos desenvolvendo, ainda não tivemos uma ativação final, já que estamos em fase beta. No entanto, já defini as métricas que vamos acompanhar após o lançamento para os usuários finais. Como se trata de um produto interno para a ONG, nosso foco será em engajamento, adoção e satisfação. Optamos por métricas como adoption rate, para medir quantos profissionais e pacientes realmente utilizam a solução, CSAT para avaliar a satisfação, e daily active users, que nos ajuda a entender o uso recorrente.
Não aplicamos um framework específico como AARRR (métricas piratas) ou HEART, mas gosto bastante do segundo, pois estrutura bem a relação entre métricas e objetivos. Sei que em produtos comerciais, como o da Meetime, as métricas podem ser bem diferentes e incluir aspectos como taxa de conversão, CAC, LTV, churn, receita recorrente mensal e várias outras. Então, apesar de hoje acompanhar métricas mais voltadas ao contexto interno, tenho familiaridade com um conjunto mais amplo de indicadores para diferentes tipos de produto.
Como Definir as Métricas Certas para um Produto?
“Definir as métricas certas depende do objetivo do produto e do momento em que ele está. Eu gosto de começar entendendo qual problema estamos resolvendo e qual comportamento queremos incentivar. A partir disso, escolho métricas que realmente reflitam o sucesso dessa solução.
Por exemplo, se for um produto voltado para aquisição de usuários, métricas como taxa de conversão, CAC e LTV fazem sentido. Se for um produto interno, como o que estamos desenvolvendo na ONG, métricas de adoção e engajamento, como adoption rate e daily active users, são mais relevantes.
Outro ponto importante é evitar métricas de vaidade, que podem parecer boas no papel, mas não geram insights acionáveis. Prefiro usar frameworks como o HEART, que ajuda a conectar métricas a objetivos, ou o AARRR, que estrutura bem o funil de crescimento.
No fim, definir boas métricas envolve entender o que realmente indica valor para o usuário e para o negócio e garantir que os dados coletados sejam acionáveis para orientar decisões.”
O que são métricas acionáveis?
Métricas acionáveis são aquelas que realmente ajudam a tomar decisões e guiar melhorias no produto. Elas indicam um comportamento concreto dos usuários e podem ser influenciadas diretamente por mudanças no produto ou estratégia.
🔹 Exemplo de métrica acionável: Taxa de retenção de usuários. Se ela cair, você pode investigar possíveis problemas na experiência do produto e agir para melhorar.
🔹 Oposto de métrica acionável: Uma métrica de vaidade, como número total de acessos ao site, que pode crescer sem necessariamente indicar sucesso ou guiar ações estratégicas.
Uma boa métrica acionável é específica, mensurável e ligada a objetivos de negócio.
Exemplo de Métrica de Sucesso:
Sucesso do Produto pode ser medido pelo número de usuários ativos mensais (MAU), taxa de retenção e NPS, por exemplo. Para um produto digital, essas métricas ajudam a entender se os usuários estão se engajando de maneira sustentável e se eles recomendariam o produto a outros.
Como Monitorar e Iterar com Base nas Métricas?
A coleta de métricas deve ser contínua e as iterações devem ser feitas com base nos insights extraídos dos dados. Uma mudança na experiência do usuário ou nas funcionalidades deve ser testada com A/B testing para medir o impacto e ajustar conforme necessário.
Algumas ferramentas para acompanhamento de métricas
Ferramentas como Google Analytics, Mixpanel, Amplitude, Tableau, Looker, entre outras, podem ser usadas para rastrear essas métricas e visualizar os dados de forma eficaz.
Como priorizar o backlog de produto?
Eu priorizei o backlog combinando a abordagem MoSCoW para definir o escopo essencial do MVP e RICE para ordenar as iniciativas dentro de cada categoria.
Primeiro, no discovery, identifiquei os problemas críticos dos usuários e agrupei as funcionalidades em Must Have, Should Have e Could Have, garantindo que o MVP entregasse o mínimo viável de valor. Depois, dentro das categorias que ainda tinham várias iniciativas, apliquei RICE para classificar quais tinham maior impacto e menor esforço, garantindo um desenvolvimento eficiente.
Além disso, levei em conta restrições técnicas e alinhamento com os objetivos do produto, ajustando a priorização sempre que surgiam novas informações ou mudanças de contexto.
como você mede sucesso de uma feature ou produto?
Para medir o sucesso de uma feature ou produto, eu me baseio em uma combinação de métricas qualitativas e quantitativas, alinhadas aos objetivos principais do produto. No caso da plataforma que estou ajudando a desenvolver para a ABNMO, que visa gerenciar o fluxo de atendimento ao paciente, algumas métricas-chave que eu usaria para medir o sucesso de uma funcionalidade incluem:
- Engajamento do Usuário:
> Taxa de uso da funcionalidade: Quantos pacientes e profissionais de saúde estão utilizando a nova feature? Para a plataforma da ABNMO, isso pode ser medido pela quantidade de usuários que acessam e completam as etapas do cadastro ou interação com o formulário de atendimento.
> Frequência de uso: Como os usuários estão interagindo com a plataforma? Eles estão utilizando-a de forma contínua? A plataforma precisa ser algo que os usuários consultam frequentemente, então acompanhar a frequência de login ou de uso das ferramentas de assistência médica será importante. - Eficiência e Adoção:
> Tempo para completar ações: Por exemplo, se estamos falando do formulário de cadastro ou de um processo de agendamento de consultas, medimos quanto tempo o usuário leva para completar cada tarefa. O objetivo é otimizar essas etapas, tornando-as mais rápidas e intuitivas. Reduzir o tempo de preenchimento, por exemplo, é uma métrica importante.
> Taxa de conversão: Quantos usuários estão completando o fluxo do cadastro? Se uma feature não está sendo completada (por exemplo, pacientes não estão finalizando o cadastro), podemos investigar possíveis barreiras e otimizar a experiência. - Satisfação e Feedback dos Usuários:
> Net Promoter Score (NPS): Um indicativo direto de como os usuários se sentem em relação à plataforma. Para a ABNMO, isso poderia ser medido perguntando aos pacientes e profissionais de saúde se recomendariam a plataforma para outras pessoas com NMO.
> Feedback qualitativo: Coletar feedback diretamente dos usuários após a implementação de novas funcionalidades ou mudanças. Isso pode incluir entrevistas com pacientes ou profissionais de saúde para entender a experiência deles e possíveis pontos de melhoria. - Impacto no Resultado de Negócio:
> Aumento de métricas de saúde e atendimento: O sucesso de uma funcionalidade também deve ser medido com base no impacto real no fluxo de atendimento. Como a plataforma está ajudando a melhorar a eficiência do atendimento? Se a funcionalidade é voltada para agilizar o preenchimento de dados ou acelerar o processo de triagem de pacientes, o sucesso seria visto na redução de tempo de espera e no aumento da capacidade de atendimento.
> Aumento de doações: Se a funcionalidade tem um impacto no processo de doações, podemos olhar para métricas de conversão de doadores ou até mesmo a qualidade dos dados coletados (informações mais detalhadas que podem ajudar a atrair mais doações). - Impacto na Acessibilidade e Inclusão:
> Como o produto está ajudando a tornar o atendimento mais acessível para todos os pacientes, especialmente aqueles com NMO? Por exemplo, monitorar se as funcionalidades de suporte (como assistência personalizada ou opções de comunicação) estão facilitando o acesso de pacientes em regiões mais remotas ou com diferentes níveis de conhecimento tecnológico.
como voce lidaria com requerimentos conflituosos de stakeholders?
Se eu me deparasse com requisitos conflitantes de stakeholders, eu começaria alinhando as prioridades com base nos objetivos de negócio e nas necessidades dos usuários. Procuraria entender as motivações por trás de cada solicitação e usaria dados para embasar as decisões. Em seguida, faria uma mediação entre as partes envolvidas, buscando compromissos sempre que possível, e, quando necessário, apresentaria soluções alternativas que atendem ao máximo possível das necessidades de todos.
Além disso, eu manteria uma comunicação constante e transparente, para garantir que todos os stakeholders estivessem cientes das decisões tomadas e das razões por trás delas, garantindo o alinhamento contínuo e a colaboração no processo.
Um exemplo real:
Um exemplo que tive foi em um projeto em que o time estava discutindo a escolha entre microserviços e um banco de dados monolítico. O time de DevOps preferia a arquitetura de microserviços, pois acreditava que isso traria maior escalabilidade e facilidade para implementar novas funcionalidades de maneira independente. Já os Tech Leads defendiam um banco monolítico, pois acreditavam que a simplicidade na estrutura inicial seria mais adequada para o MVP, além de ser mais fácil de gerenciar em termos de integração entre diferentes partes do sistema.
Para resolver esse conflito, organizei uma série de discussões técnicas, com o objetivo de entender as necessidades imediatas do projeto e as previsões de crescimento. Avaliamos o impacto de cada abordagem no curto e longo prazo, considerando a escalabilidade do produto, o tempo de desenvolvimento e os custos de manutenção.
Chegamos a um meio termo, decidindo por uma abordagem híbrida: começamos com uma arquitetura monolítica para o MVP, o que permitiu agilidade e foco na entrega rápida de valor. Mas com um planejamento claro para refatorar para microserviços à medida que a aplicação crescesse e a demanda por escalabilidade se tornasse mais relevante. Essa solução atendeu tanto às necessidades de curto prazo quanto às exigências de escabilidade futura.
como é um bom user story?
Um bom user story deve ser claro, conciso e focado no valor que será entregue ao usuário. Ela deve seguir um formato simples que facilita a compreensão por todos os membros do time. Uma estrutura comum para um user story é:
Como [tipo de usuário], eu quero [ação] para que [benefício/valor].
Aqui estão algumas características de um bom user story:
Clareza e foco: A história deve ser fácil de entender por todos os envolvidos (produto, design, desenvolvimento). Ela deve ser voltada para o valor do usuário, sem ambiguidade.
Valor claro: A história deve mostrar claramente como ela agrega valor ao usuário ou ao negócio.
Tamanho adequado: Não deve ser nem muito grande (como uma épica) nem muito pequena (como uma tarefa técnica). O ideal é que seja algo que possa ser desenvolvido em um sprint, mas que possa ser subdividido se necessário.
Critérios de aceitação: Os critérios de aceitação detalham o que precisa ser feito para que a história seja considerada completa. Isso ajuda a alinhar expectativas.
como voce explicaria o que é ser um product manager para um leigo?
Como eu respondi até na candidatura de vocês, para mim, ser Product Manager é ter a habilidade de entender profundamente as necessidades do negócio – seus objetivos, os recursos e as prioridades – enquanto também identifica as dores e expectativas dos usuários, inclusive aquelas que eles nem sempre conseguem expressar claramente. É trabalhar na interseção dessas duas pontas, conectando os times técnicos e garantindo que todos estejam alinhados.
É quase como o trabalho de um arquiteto: traduzir a visão do cliente em um projeto técnico que seja viável e equilibrado para ambas as partes – o escritório de arquitetura e o cliente que contratou o projeto. O arquiteto precisa priorizar tarefas, garantir que os prazos sejam consistentes e assegurar que todos os envolvidos na execução tenham as ferramentas e informações necessárias para realizar o trabalho, respeitando o expertise e as funções de cada profissional.
como voce explicaria o que é uma sprint para um leigo?
Imagina que você está planejando uma viagem para um destino incrível, mas não quer esperar até o final da viagem para ver os resultados. Então, você decide dividir a viagem em etapas menores. A cada semana, você estabelece um mini-destino, como visitar um parque ou uma atração específica. Cada vez que chega no final de uma dessas etapas, você se sente realizado porque avançou em direção ao objetivo maior, e também consegue ajustar a rota se algo não estiver funcionando bem. No contexto de um time de produto, a sprint é essa ‘etapa da viagem’ onde focamos em entregar uma parte importante do que queremos alcançar, sempre revisando o progresso e fazendo ajustes quando necessário.
como voce se mantem informado de novidades na industria e de competidores?
Eu sou bastante fã de newsletters e podcasts, pois acredito que esses canais oferecem uma maneira prática de me manter atualizado. Assino a Lenny’s Newsletter e a Mind the Product, que são fontes incríveis sobre produto, além de continuar me aprofundando com cursos da PM3, que me ajudam a entender melhor as melhores práticas e metodologias atuais. Também acompanho o Mesa de Produto, o podcast deles, que traz entrevistas com grandes profissionais da área.
Além disso, me mantenho atenta às tendências do mercado e à evolução da tecnologia. Ouço o Product’s Guru, um podcast brasileiro focado em inovação e tendências no universo de produtos e no mercado como um todo. Para entender as novas tecnologias e inovações, também sigo sites como TechCrunch, Wired e alguns blogs especializados em IA e startups. Dessa forma, consigo não só me atualizar sobre a área de produto, mas também sobre os avanços tecnológicos e o impacto deles no mercado.
descreva seu processo de obter e priorizar feedback de usuarios
Meu processo atual de coletar e priorizar feedbacks é uma combinação entre prática em projetos reais e estudos de frameworks que quero aplicar. Vou dividir em etapas:
- Coleta de Feedback
> Como faço hoje:
No projeto do IpêCode, realizamos testes beta com protótipos de alta fidelidade no Figma. Convidamos equipes médicas para simular o uso do produto, observando onde eles travavam ou expressavam frustrações. Por exemplo: em uma tela de registro de pacientes, 8 em 10 usuários pediam menos campos obrigatórios.
Canais: Usamos sessões remotas gravadas e formulários pós-teste com perguntas como “O que te faria usar isso diariamente?”.
Fonte secundária: Reúno insights indiretos do time de Customer Success, que tem contato direto com os hospitais.
> O que estudei e quero implementar:
Aprendi que o JTBD (Jobs to Be Done) ajuda a ir além do feedback superficial. Em vez de só perguntar “O que você quer?”, focaria em “Qual ‘trabalho’ você está tentando realizar?”. Por exemplo: no IpêCode, descobrir se o “job” dos médicos é “rastrear histórico de medicamentos” ou “reduzir tempo de documentação”.
- Priorização
> Como faço hoje:
Uso o MoSCoW para uma triagem inicial. No IpêCode, classificamos como:
Must have: Funcionalidades críticas, como alertas de interação entre medicamentos (priorizadas após 5 hospitais relatarem erros).
Could have: Melhorias incrementais, como exportar relatórios em PDF (útil, mas não urgente).
> O que estudei e quero implementar:
Quero adotar o RICE (Reach, Impact, Confidence, Effort) para decisões mais precisas nesses ciclo de freedback. Por exemplo:
Impact: Se uma feature economiza 2h semanais por usuário (baseado em feedbacks), o impacto é alto.
Confidence: Validaria com testes A/B ou dados históricos (ex: taxa de retenção após a mudança).
- Validação e Iteração
> Como faço hoje:
No lançamento de uma nova funcionalidade, monitoro métricas como taxa de conclusão de tarefas e feedbacks qualitativos em tempo real. Por exemplo: após simplificar a tela de cadastro, o tempo médio de registro caiu 30%.
> O que estudei e quero implementar:
Li o livro “Continuous Discovery Habits” e pretendo criar um hábito de entrevistas contínuas (ex: 1 entrevista/semana com usuários-chave) para validar hipóteses antes de escalar features.
o que voce faria se no meio da sprint voce descobrisse que o time nao vai ser capaz de entregar o planejado?
Se eu percebesse que o time não conseguiria entregar o planejado no meio da sprint, eu começaria entendendo o que aconteceu. Conversaria com a equipe pra ver onde estão os bloqueios, se alguém precisa de mais ajuda ou se surgiu algum imprevisto.
Com isso, eu tentaria ajustar o escopo, cortando ou diminuindo um pouco algumas tarefas menos urgentes, pra garantir que o que é mais importante seja entregue. Eu também falaria com os stakeholders, explicando a situação e alinhando as expectativas.
E claro, na sequência, a gente tentaria identificar o que causou esse problema pra evitar que aconteça de novo no futuro, seja resolvendo algum processo ou oferecendo mais suporte pra equipe.
Como você prioriza as necessidades dos usuários em relação às restrições de tempo e recursos?
Utilizo uma abordagem baseada em impacto e esforço. No webapp, por exemplo, a ong pedia uma funcionalidade de exportação de dados em PDF, mas o desenvolvimento demandaria 3 sprints. Ao analisar os dados de uso, percebi que 80% dos usuários preferiam visualizar os dados diretamente na plataforma. Priorizei, então, melhorar a visualização em tempo real e adiei a exportação para uma versão futura, liberando recursos para otimizar o fluxo de registro de pacientes – uma demanda crítica com maior retorno. Para decisões como essa, sempre equilibro feedback qualitativo (entrevistas) com dados quantitativos (taxas de uso).
Quais são alguns dos seus maiores pontos fortes como Product Manager Júnior?
Acredito que meu maior ponto forte é a empatia, no sentido de entender ambientes e as pessoas, de observar situações, de tentar calçar o sapato do outro para entender contextos diferentes do meus. Ainda como jornalista e não só como jornalista, mas também como produtora de conteudo para marcas, eu aprendi a deixar minhas próprias convicções de lado e me colocar no lugar de outras pessoas, seja representando uma marca em uma comunicação ou fazendo a ponte entre informações super técnicas de um especialista com leitores de uma revista, deixando suas opiniões e maneirismos de lado. Quando eu passei a atuar como PO, eu vi que essa habilidade me foi muito util, especialmente nas entrevistas de usuario durante o discovery
E eu tenho uma grande paixão por aprender. Nunca parei de estudar, de testar novas ideias e descobrir novas ferramentas pra otimizar o meu trabalho. Eu sou uma profissional que não tem medo de entrar em contato com novos conceitos, novas ferramentas, novas maneiras de trabalhar.
Por fim, reconheço que sei me adaptar facilmente. Já gerenciei equipes com perfis diversos, incluindo vários níveis de senioridade. Trabalhei de perto com todos, desde o CEO até estagiários de produção de conteúdo, além de clientes e a equipe de vendas. Essa experiência me ajudou a desenvolver a capacidade de ajustar meu estilo de comunicação e entender como posso contribuir em diferentes áreas, reconhecendo a importância de cada stakeholder em cada aspecto do meu trabalho.
