O primeiro ano como PM de um produto global

Como evoluímos nossa visão de "empower commerce" de forma leve e adaptativa

Moacyr Viegas
olist
7 min readMar 23, 2021

--

Eu imagino que o sonho de muitos PMs seja criar um produto de sucesso. Ou não… Muitas das jornadas que vivi nos últimos anos me ensinaram coisas diferentes e complementares sobre produto e foi tão enriquecedor quanto começar um do zero.

saudades do escritório que fala, né?

Não sei como você classifica um produto como sucesso, mas o nosso shops chegou a 200K usuários, mais de 180 países e muitas das nossas métricas seguem melhorando. Com a função de simplificar a forma como pequenos varejistas criam e gerenciam seu negócio online e seus números, entendo que ele caminha para uma jornada de sucesso.

Em março de 2021, esse pequeno jovem digital completou sua primeira volta ao Sol online, visitando diversos cantos por meio das app stores e ajudando muitos pequenos lojistas a começarem sua trajetória de vendas nessa tal de internet.

Essa jornada inicial foi rica em desafios e não só o produto evoluiu como eu também, e acredito que os parágrafos abaixo sintetizam um pouco dessa experiência.

Menos mimimi de processos rígidos, mais o que nos faz melhor hoje

O playbook padrão de produto prega diversas etapas para se chegar ao código. Pensamos em pesquisa de mercado, hipóteses, discovery, teste de usabilidade, abre diamante, fecha diamante, refina história, pontua, codifica, testa… Ufa, jornada longa, né? Não se esquece de acrescentar que precisa ter um mvp ai no meio.

Mas você ja trabalhou em uma startup? Se não, vamos aos fatos: a vida é um eterno “sem tempo, irmão, só vamos”.

Não vou entrar no mérito de como chegamos à “iniciativa shops”, pois nossa área de Produto & Design se preocupa muito mais em entender os principais problemas e oportunidades independente de onde surgiu a ideia geral e 2020 foi o ano de tirar essa ideia do papel.

O fato é que em janeiro de 2020, em Curitiba, eu conheci um time que, em grande parte, tinha acabado de entrar no olist e que tinha uma missão de ter esse app em algumas semanas. Foi isso: uma ideia, uma solução, um time, muitas hipóteses, pouquíssimo tempo.

Beleza, e daí?

E aí que sem tempo o processo de produto se ajusta: premissas, acordos, desenhos no papel, validações de corredor e decisões rápidas — 1 semana pensando em algo que vai ser simples de qualquer jeito ou 1 semana desenvolvendo a primeira versão simples desse algo?

Esse cenário nos fez iniciar uma forma de trabalho interessante que trazemos até hoje, mesmo tendo um pouco mais de tempo que no começo: o nosso contrato. Esse artefato nosso de cada dia nos permite que cada stack, área, pessoa, consiga iniciar um desenvolvimento sem que haja bloqueio de outra, desde que ela siga o que foi acordado.

Nosso contrato e o dia a dia mobile vs web

Sabe aquela parte do processo que diz que uma história precisa entregar valor final ao usuário para ser desenvolvida? Pois bem, tenta pensar em escrever ela pra que múltiplas pessoas trabalhem ao mesmo tempo, com milhares de subtasks.

Com histórias muito pequenas, todo esse fluxo funciona. Mas quando pegamos tarefas mais complexas, no geral se gasta mais tempo para atender ao processo do que adequar ao que melhor atende o dia a dia de cada time.

Nosso fluxo sempre foi pautado pelo desenvolvimento modular e constante alinhamento entre cada uma das frentes que ali trabalhavam. Não faz sentido ter uma ou duas partes do time paradas por uma dependência com a terceira.

Prezamos, até hoje, pelo fluxo adaptado à nossa realidade diária versus processos travados. Após as primeiras semanas quebrando a cabeça sobre se encaixar no processo, observamos que nossa dinâmica funcionaria se tivéssemos um contrato: se todos partirem de um mesmo ponto, com as mesmas instruções e falarem a mesma coisa durante todo o percurso, não teremos muitas surpresas no destino

O problema: esse fluxo gera um overhead de alinhamento e aumenta o risco no médio prazo, uma vez que não seguimos a regra de ouro de todos do time estarem atacando uma iniciativa ao mesmo tempo e, por consequência, tratamos de muitas frentes em paralelo. Mas, de novo, você já trabalhou em uma startup? E em uma que criou um novo produto do zero?

Nosso desafio diário é: como não transformar uma funcionalidade em cascata e ao mesmo tempo não travar ninguém porque existem dependências entre stacks (back, web e mobile) e fluxos?

Como funciona esse contrato, então?

Ao iniciar cada nova discussão de iniciativa, definimos o escopo em conjunto: business, tech, design, ops, growth, produto e quem mais estiver envolvido. A partir desse escopo definido, é possível iniciar o desenvolvimento, o desenho de telas, material de marketing etc. Parece algo óbvio e comum, alguns diriam, mas fazemos isso com dezenas de iniciativas em paralelo e o fluxo funciona.

Em um fluxo normal, seguindo a ideia de valor completo para o usuário por tarefa, nós teríamos um use case/história em desenvolvimento com todas as stacks trabalhando ao mesmo tempo. Como comentei acima, isso poderia gerar alguns atrasos à medida que as dependências aumentam durante a mesma janela de desenvolvimento.

Separando o trabalho ao longo do tempo, temos algumas esteiras trabalhando em paralelo: funcionalidades entregues no backend, por exemplo, entram em desenvolvimento pelo frontend algumas semanas depois, facilitando todo o processo de gestão de releases e testes e ainda otimizando nosso fluxo de desenvolvimento.

Um produto global e a regionalização de fluxos

O playbook tradicional talvez pregasse que fizéssemos primeiro um país, validássemos e ai iniciaríamos outro. Contudo, nós optamos por uma jornada mais complexa: compreender o comércio na sua essência de forma que um app pudesse atender as necessidades de pequenos lojistas de forma global.

A maior dificuldade nesse sentido é que, como você pode imaginar, os países possuem peculiaridades legais, monetárias, culturais, linguísticas e por aí vai. Como é o CPF da Rússia, por exemplo?

Nossos discoveries passaram a considerar esse tipo de input e nossa operação diária passou a se perguntar: como eu desenvolvo esse pedaço de forma que ele atenda o mundo inteiro e ainda sim não vire um monstro cheio de regras? A linha entre desenvolver algo simples e flexível e desenvolver algo que da muitas voltas e demanda muito trabalho de manutenção costuma ser muito sútil e de fácil confusão (palavra errada no final).

Funcionalidade à funcionalidade, sentamos pra entender como ela evolui globalmente e como ela se conecta aos nossos próximos passos, dado que lidamos com vários níveis de desenvolvimento em cada país.

O risco que evitamos com essa escolha foi de não especificar muito o desenvolvimento em um país inicial e depois ter dificuldades para regionalizar a plataforma. Esse processo de internacionalizar produtos locais, por experiência própria, se torna cada vez mais complexo com o crescimento do produto e das regras de negócio envolvidas, gerando um trabalho gigantesco de desenvolvimento e readaptação de fluxos.

Usuários, testes e uma pandemia

Como comentei, shops começou seu desenvolvimento em janeiro de 2020 e a nossa versão 1.0 foi colocada no ar exatamente 5 dias antes de, por exemplo, o governador de São Paulo decretar quarentena no Estado.

Photo by Edwin Hooper on Unsplash

Naquele cenário, apesar de um valor limitado, shops entregava muito do que era necessário pro momento: uma forma simples de se ter seu catálogo online.
Nossa expectativa de rodar algumas semanas com poucos usuários se tornou uma boa emoção: usuários, signups, produtos, chamados, solicitações, reclamações.

Lembro de que no quarter seguinte ao lançamento, todas as métricas pareciam confusas: muitos dos nossos fluxos simplificados estavam sendo estressados ao máximo por diferentes perfis de usuários no mundo inteiro. Ao mesmo tempo, todas elas não se conversavam e ainda evoluíam.

Nosso lançamento naquele momento foi um teste por si só. Qualquer alteração de fluxo permitia avaliar diversos comportamentos dos usuários devido ao volume total.

Foi o teste perfeito: um MVP, muitos usuários, alto volume de dados e feedbacks. E foi um teste emocionante, pois a pressão de entregar melhorias e atender esses usuários é cada vez maior: nós evoluímos, eles evoluíram, o mercado evoluiu. Todo o cenário de março de 2021 é diferente do cenário de março de 2020. A única coisa constante é a demanda de boas soluções para as necessidades dessas pessoas.

Como chegamos até aqui, afinal?

Na prática, este texto conta muito pouco da nossa jornada diária. Mas ele traz alguns tópicos gerais: não temos frameworks famosos que nos trouxeram até aqui e não brigamos constantemente por processos bem estruturados, não seguimos nada by the book, não temos quem copiar de fato.

Nós temos 2 pilares básicos: método e confiança! Nosso time é muito experiente (de longe, um dos melhores que já trabalhei) e, portanto, com expertises próprias, cada integrante ajuda a moldar nosso processo diariamente.

Mas além de método e pessoas brilhantes, um componente importante foi a confiança. Confiar que seu par fará o melhor em meio a um processo não linear e complexo, que muda todo dia, em um segmento de varejo que é super dinâmico, atuando globalmente em uma pandemia foi fundamental para o nosso sucesso.

Já comentei com muitas pessoas que shops foi um presente: uma grande missão, guiada por grandes valores e um time espetacular. Estamos revolucionando a forma de construir sua loja online de uma forma leve e comprometida.

Achou nosso processo legal? Achou que ele pode melhorar?
Temos vagas para os 2 casos! Bora revolucionar a forma como pequenos lojistas trabalham online no mundo todo.

--

--

Moacyr Viegas
olist
Writer for

Lead Product Manager @ olist ~ economista que se perdeu nas contas e se encontrou no mundo digital.