Um Product Manager vive de resolver problemas. Basicamente é isso que fazemos o tempo todo, recebemos ou encontramos um determinado problema e damos um jeito de resolve-lo. Nessa jornada, normalmente uma parte importante do processo acaba se perdendo, a definição do problema! Nosso instinto quando se pensa em resolver um problema, é, naturalmente, buscar uma solução. Mas o grande desafio para um gestor de produto não está em solucionar o problema em si, o grande desafio está em definir o problema que precisa ser resolvido.
Problemas estruturados x não estruturados
O problema começa na forma como pensamos. Desde a escola, passando pela universidade e basicamente em qualquer outra experiência acadêmica que você teve, estamos acostumados a pensar em problemas estruturados. Basicamente isso quer dizer que todos os problemas que vimos até sairmos da faculdade tem um começo, um meio e um fim muito bem definidos. Para todos os problemas, até então, existia uma descrição do que precisava ser resolvido (começo) e um conjunto de fórmulas e/ou fontes de informação (meio) que te levariam a uma resposta esperada (fim), a resposta certa.
Pois bem, o tempo passou e, no mundo real, as coisas funcionam de uma forma levemente diferente. Os problemas que temos que resolver, enquanto Gerentes de Produto, são, geralmente, não estruturados… ou pelo menos os mais desafiantes deles. A nossa primeira falha está em justamente tratar os problemas não estruturados como se eles fossem estruturados. Dessa forma, ficamos em busca da tal resposta certa que estamos acostumados. Obviamente, ela nunca será encontrada.
Isso quer dizer que não importa quantos blog posts você leia, quantos cursos você faça ou quantos especialistas você consulte… simplesmente não existe uma fórmula mágica para resolver o problema que está na sua frente e muito menos uma resposta certa para ele. Problemas não estruturados são não estruturados justamente porque eles não possuem uma única definição ou representação. Cada um que olhar para o problema, possivelmente, vai enxergar algo novo ou ao menos diferente. Sendo assim é impossível encontrar uma única maneira de resolve-lo e responde-lo.
A sua mágica, como Product Manager, está justamente em definir muito bem o problema, para que, ai sim, o time todo possa trabalhar para resolve-lo. Ou seja, o principal foco de um PM deveria ser em definir e priorizar problemas e não em pensar nas soluções para esses problemas. Inclusive, conceitualmente, é muito mais provável que você resolva esse tipo de problema através de um processo de design do que tentar chegar a uma solução através de uma busca sistemática, como se fosse um algorítimo matemático. Mas isso é assunto para um próximo post.
Definindo o problema
O primeiro passo é entender onde estamos pisando. Isso pode ser feito de várias formas, mas quase todas elas passam por algum tipo de análise exploratória. Essa análise inclui entrevistas qualitativas com clientes e com o próprio time interno. Idealmente, deve passar também por uma etapa de análise de dados, para tentar encontrar correlações e/ou comportamentos semelhantes entre os usuários da sua base. As descobertas dessa análise podem servir de input para a etapa de entrevistas qualitativas ou para confirmar os outputs dela.
Outra fonte de informação muito rica nessa etapa é o suporte do seu produto. Lá você deve encontrar várias informações sobre como os seus usuários estão utilizando o seu produto e quais problemas eles estão enfrentando. Ao fim dessa etapa o próximo passo é documentar todo esse aprendizado.
Nesse ponto você já deve ser capaz de entender muito bem o problema que você precisa resolver e, consequentemente, conseguir defini-lo com uma boa precisão. Além disso, já deve ter ficado claro como você pode quebrar este problema inicial em outros problemas menores, mais fáceis de serem resolvidos. Sendo assim, é importante colocar tudo isso no papel. Além de facilitar o acesso a essa informação no futuro, tanto por você mesmo quanto por outras pessoas do seu time, documentar as suas descobertas vai lhe ajudar a pensar melhor sobre o problema e conseguir argumentar melhor a respeito dele quando for questionado sobre o assunto.
Eu, particularmente, gosto de documentar o problema em um documento que contenha o objetivo e a motivação que gerou o estudo, uma descrição do problema macro e um detalhamento dos problemas que surgiram a partir dele. Além disso o documento deve conter uma lista priorizada destes problemas menores, para serem enfim solucionados pelo seu time.
No futuro, cada problema destes deverá ter várias soluções possíveis. Cada uma delas com vantagens e desvantagens. Caberá a você, como PM e “detentor” do problema, ajudar o time a a escolher a solução que melhor irá resolver o problema definido. Se você quiser saber mais sobre assunto recomendo bastante a leitura deste excelente post da Teresa Torres.
