‍

O produto em questão é um SaaS para gestão de empresas, que possui um módulo específico para gestão financeira. O módulo financeiro era tido como o principal motivo de avaliações negativas, detratores e churn na plataforma.

Alguns parceiros estrategicamente importantes (key accounts) começaram a expressar seu descontentamento com a ferramenta, chegando até ameaçar o cancelamento. Podemos adicionar a esse cálculo também o número de novos usuários que deixaram de entrar na plataforma devido a esse déficit.

O projeto demandava repensar toda a experiência do usuário com o financeiro de forma modularizada, para atacarmos os pontos mais importantes e realizarmos entregas mais rápidas e em partes. Para chegarmos no resultado obtido, dois pontos foram de extrema importância para o sucesso da solução: a adaptabilidade e a colaboração intersetorial.

‍

‍

Levando em consideração as limitações do time, a adaptabilidade é o primeiro ponto que norteou todo o processo. O nosso time de produto era composto por três pessoas: um Product Manager (Pedro Henrique) e uma dupla de Product Designers (a qual fazia parte com o Luan Costa), que atuavam em todos os processos do Discovery ao Delivery (descoberta até a criação e entrega das interfaces).

Sou suspeita pra falar, mas nosso dream team era composto por profissionais competentes, talentosos e estratégicos, mas sendo o único time de produto para um software extenso e complexo que possui 5 módulos (o financeiro é apenas um deles), é preciso muita adaptabilidade para conseguir lidar com todas as demandas do dia a dia.

É de extrema importância adaptar os frameworks existentes à realidade de cada equipe e empresa, especialmente quando o time é limitado em quantidade de pessoas e recursos disponíveis. Cada organização possui suas particularidades, desafios e necessidades específicas, e adotar uma abordagem flexível é fundamental para obter sucesso, otimizando a eficiência e a produtividade.

Dessa forma, é possível maximizar o potencial do time, focar em atividades de maior valor e alinhar as estratégias de produto com as metas e objetivos da empresa. A capacidade de adaptar-se e personalizar os frameworks existentes demonstra a habilidade de um time de produto em se adequar às circunstâncias e encontrar soluções criativas para os desafios enfrentados, resultando em melhores resultados e um produto de maior qualidade.

‍

‍

O segundo ponto que foi de extrema importância para todo o processo foi a colaboração intersetorial. Construir uma experiência assertiva abrange não apenas a estética e a usabilidade do produto, mas também a compreensão das necessidades, expectativas e comportamento dos usuários.

Um time de design realiza diversas pesquisas e entrevistas com usuários, mas não tem um contato diário com eles. E quem melhor do que as pessoas que escutam os usuários todos os dias para ajudar na construção do produto?

Ao pedir ajuda de profissionais que trabalham com atendimento ao cliente (Customer Success, Suporte Técnico, Especialista em Treinamento de Clientes e outros) durante a construção da solução, é possível obter uma visão abrangente e diversificada do ecossistema do produto com feedbacks direto dos usuários finais.

A colaboração intersetorial permite que cada equipe compartilhe suas perspectivas e conhecimentos específicos, resultando em insights valiosos para melhorar a experiência do usuário.

‍

‍

As metodologias que utilizamos para resolver o problema do módulo financeiro foram as seguintes:

• Problem Solution Fit Canvas
• Triple Track Agile
• Design Sprint

O que é

É uma ferramenta utilizada no processo de desenvolvimento de produtos ou serviços para validar a relação entre o problema enfrentado pelos clientes e a solução proposta.

O quadro é dividido em duas seções principais: o lado esquerdo, que se concentra no problema, e o lado direito, que se concentra na solução. Cada seção possui componentes específicos:

‍

Ao preencher o quadro, as equipes podem visualizar claramente como os elementos do problema e da solução se alinham e se há um ajuste entre eles. Isso permite a identificação de possíveis lacunas ou falhas na proposta, bem como insights sobre como ajustar ou melhorar a solução para atender melhor às necessidades dos clientes.

Como adaptamos

Normalmente o Problem Solution Fit é uma ferramenta utilizada durante a fase inicial de desenvolvimento do produto, ajudando as equipes a validar suas hipóteses, entender o mercado e direcionar seus esforços para alcançar um ajuste sólido entre o problema e a solução. No entanto, no nosso caso, o produto já está consolidado no mercado e não estávamos em fase inicial, mas sim em uma fase de correção e aprimoramento.

Para adaptar, utilizamos o framework para “apagar o incêndio” que estava acontecendo. O canvas foi construído colaborativamente com outras áreas da empresa, e ao final da construção chegamos nos principais problemas, separados em duas partes: o que pode ser resolvido a curto prazo e o que precisa de mais estudo.

Com isso, unimos todos os problemas que poderiam ser resolvidos a curto prazo, como bugs e ajustes simples de usabilidade, e criamos pequenas tarefas para o time de desenvolvimento como medida paliativa. Assim, gerando valor rápido para nossos clientes.

Com o “incêndio apagado”, estávamos prontos para começar a “arrumar a casa” com mais tranquilidade nos próximos passos.

‍

O que é

O Triple Track não é um termo muito conhecido, a primeira vez que escutei sobre ele foi em uma Masterclass da Mergo e me interessei muito no assunto. Em seguida apresentei a ideia para o time e todos se empolgaram em adaptar alguns conceitos da metodologia e implementar na nossa rotina, substituindo o Double Diamond pelo Triple Track em alguns casos.

O termo Triple Track Agile foi cunhado por Renato Caliari, e é um processo que distribui o desenvolvimento de produto em três trilhas:

‍

1. Problem space — entender o espaço do problema e desprender das soluções

Nessa trilha, que acontece em seu próprio ritmo, entrevistas são utilizadas para mapear as necessidades e princípios norteadores do usuários, entendendo melhor o público para diferenciar o produto no mercado.

“No Problem Space o aprendizado se constrói aos poucos e é duradouro. Ele não se perde com simples mudanças da tecnologia pois não é acoplado a qualquer solução.”
— Renato Caliari

2. Solution Space — Discovery — Descoberta da solução mais adequada

Etapa para explorar, compreender e validar oportunidades, necessidades e desafios dos usuários e do negócio, assim como definir a estratégia de produto. Durante esse processo, são realizadas pesquisas, entrevistas e análises de mercado para identificar problemas, oportunidades e insights que orientarão a criação das soluções.

3. Solution Space — Delivery — Execução e entrega da solução

A trilha de Delivery é a mais comum nas empresas, é onde entra a execução de todos os estudos anteriores.

“A cada entrega nessa trilha, novas evidências surgem e nos dão mais insumo para a trilha de Discovery e até novas questões para explorar no Problem Space.”
— Renato Caliari

Para quem deseja se aprofundar no Triple Track Agile, recomendo fortemente o artigo Triple Track Agile: uma combinação de Problem Space com Solution Space do Renato Caliari.

Como adaptamos

‍

‍A pesquisa

Planejamos o Problem Space (pesquisa) definindo os métodos que seriam utilizados e que mais se encaixavam na estrutura do nosso time. A pesquisa envolveu as seguintes etapas:

• Desk Research, momento de olhar para fora: começamos coletando informações e dados do mercado atualmente, com estudos, relatórios, artigos e documentos, a fim de obter insights e mais embasamento sobre o tema.
• Pesquisa interna, momento de olhar para dentro: coletamos informações internas sobre tudo que envolvia o módulo financeiro, como avaliações de NPS, análise de justificativas de cancelamentos dos usuários, formulário interno enviado para os colaboradores para entender mais sobre a opinião interna, análise de atendimentos ao cliente via chat e uma análise dos principais insights recolhidos nessa etapa, como dores de uso, oportunidades de melhoria e novas funcionalidades.
• Análise de pedidos de produto, momento de olhar para o que os usuários pedem: o time de suporte registra todos os pedidos de produtos realizados pelos usuários, analisamos tudo que era relacionado ao financeiro e dividimos os pedidos em três sessões: contemplar agora, pensar no futuro e descartado.
• Canvas de proposta de valor: convidamos pessoas de diversas áreas da empresa e todos colaboraram para a criação do canvas de proposta de valor, pensando juntos em como atender às necessidades e desejos dos clientes no módulo financeiro.
• Benchmarking: analisamos o mercado para adquirir insights e identificar oportunidades de melhoria, visando alcançar maior competitividade e sucesso.
• Entrevistas com usuários, a parte mais rica do Problem Space: estruturamos um roteiro e entrevistamos diversas pessoas que faziam parte dos principais perfis de usuários que utilizam o módulo financeiro, resultando em insights valiosos para o sucesso do projeto.
• Análise de dados: analisamos cuidadosamente todos os dados obtidos até aqui, e com base nisso conseguimos definir quais seriam as próximas etapas.

Modularização

Após a análise de dados, conseguimos definir quais seriam os nossos principais pontos de ação de forma modularizada e as oportunidades que seriam trabalhadas no Solution Space. Dessa forma conseguimos planejar entregas mais rápidas e em partes.

Para definir a priorização das entregas e os temas que iríamos trabalhar primeiro, nossos princípio norteador foram os objetivos estratégicos da empresa.

Depois das prioridades definidas, chegou o momento de executar o Solution Space, e é aí que entra a próxima metodologia: Design Sprint.

‍

O que é

Processo criado pelo Google onde um grupo de pessoas se reúne por 5 dias para resolver questões críticas de negócios via design, prototipagem e teste das ideias com os usuários de forma ágil. Para quem deseja se aprofundar no assunto, recomendo o artigo Google Design Sprint: como funciona e como aplicar no seu projeto de Fabrício Teixeira.

‍

‍

Como adaptamos

Ninguém do time tinha experiência com Design Sprints, então começamos estudando juntos sobre o tema. Existem vários quadros prontos para passar pelos 5 dias intensos da metodologia, mas adaptamos completamente as etapas a nossa realidade.

Normalmente é um processo utilizado para validar ideias, mas como as ideias já haviam sido validadas no Problem Space, utilizamos o modelo de Design Sprint para conseguir mais agilidade nas nossas entregas.

Antes de realizar cada Design Sprint com os temas que havíamos definido prioridade anteriormente, organizávamos os objetivos e definíamos se precisávamos de 5 dias ou se poderia ser uma “Design Sprintzinha”, forma carinhosa que apelidamos Design Sprints que duravam apenas 3 dias.

Durante esses dias de desenvolvimento colaboramos com diversas áreas e pessoas da empresa e validamos com stakeholders e heavy users as novas estruturas. Os insights desses momentos foram estudados por todos do time: PM, product designers, desenvolvedores e c-level.

‍

‍

No estudo de caso apresentado, a combinação de metodologias, como o Problem Solution Fit Canvas, Triple Track Agile e Design Sprint, proporcionou uma abordagem eficaz para repensar a experiência do usuário no módulo financeiro. A adaptabilidade foi essencial para maximizar o potencial do time, enquanto a colaboração intersetorial trouxe insights valiosos para melhorar a experiência do usuário.

Gostaria de agradecer ao meu dream team (Pedro e Luan), por me permitir compartilhar nossas experiências aqui e a todas as pessoas que sempre colaboram com o time de produto para alcançarmos o melhor resultado possível.

Para quem quiser conversar mais sobre o assunto, pode ficar a vontade para me chamar no meu LinkedIn. Vamos nos conectar!

‍

• Como aliar UX Research e Suporte ao Cliente para fazer Pesquisas mais Rápidas por Breno Rossini.
• The Problem-Solution Fit canvas por Daria Nepriakhina.
• Triple Track Agile: uma combinação de Problem Space com Solution Space por Renato Caliari.
• Google Design Sprint: como funciona e como aplicar no seu projeto por Fabricio Teixeira.