Product Arena
O jeito mais fácil de explicar o que precisa ser feito para o time
Os três gaps que apareceram no processo de produto da InstaCarro e a estrutura de cinco blocos que passou a explicar cada demanda para o time.
Por Arthur Castro
Quando começamos a estruturar os processos de produto e design para conseguir escalar, queríamos construir algo que fosse **colaborativo** e **ágil**.  Por ser um dos princípios da InstaCarro, nós acreditamos **que é bem melhor testar com o usuário do que tomar decisões numa sala de reunião**. Tanto é que foi conversando com pessoas que aumentamos nossa conversão em quase 60%. Já tínhamos definido nossos princípios, mas precisávamos definir algumas premissas básicas para ajudar no desenvolvimento dos nossos produtos. Quando colocamos todos os envolvidos numa sala, acabamos descobrindo alguns gaps.  ## Identificar o gap não basta: é preciso testar a solução Ótimo, tínhamos identificado os principais gaps. Mas não bastava só identificar, precisávamos testar algo para resolver esses pontos. Antes de tomar qualquer atitude, novamente buscamos conversar com as pessoas, porque no final das contas, como [Simon Sinek](https://startwithwhy.com) já dizia: > "100% of customers are people. 100% of employees are people. If you don't understand people, you don't understand business" Então fizemos uma **pergunta simples** para cada um dos envolvidos: > **Pra você, como seria o fluxo ideal?** E, como imaginávamos, todas as respostas tinham vários pontos em comum. Juntando com nossas ideias, conseguimos identificar o "*fluxo perfeito*". Esse fluxo nos ajudou a mapear e identificar onde estavam os gaps: - **Não tenho visibilidade:** não tínhamos uma ferramenta para os stakeholders e todo mundo da empresa acompanhar o status das coisas que estavam sendo feitas. - **Não sei por que estou fazendo isso:** acontecia principalmente nas fases de ***ideação*** e ***refining***. Não existia um padrão para descrever por que cada coisa estava sendo feita, muito menos como isso resolveria o problema encontrado. - **Não tem nada especificado:** acontecia principalmente na fase ***ready to dev***. Os desenvolvedores sentiam falta de receber coisas básicas, como os assets, a explicação do comportamento e o que precisa ter tracking. Foi excelente mapear e identificar onde estavam os principais gaps, mas ainda faltava a ação. **Como íamos resolver isso?** ## O "trio ternura" de ferramentas  - **Não tenho visibilidade:** *step by step* do processo no JIRA. - **Não sei por que estou fazendo isso:** nosso padrão de user stories e rascunhos da jornada, wireframes no RealtimeBoard e no Marvel. - **Não tem nada especificado:** assets, comportamento e comentários, tudo mapeado e especificado no *Handoff*, feature excelente do Marvel. E chegamos nisso aqui:  *Nosso stack de ferramentas **não** está fechado. Ou seja: se em algum momento encontrarmos a necessidade de outras ferramentas que façam sentido para nós, analisamos e incluímos.* ## A estrutura que usamos para explicar o que precisa ser feito A gente acabou juntando um pouco de cada um dos modelos do mercado e encontrou **o jeito mais fácil de explicar o que precisa ser feito** para a InstaCarro. Chegamos nesta estrutura: - Hipótese / Necessidade / Bug - OKRs relacionados - O que precisamos e sugestões - Critérios de aceite - Referências e recursos E, um pouco mais detalhado, o que temos em cada uma delas. ### Hipótese / Necessidade / Bug Se algo precisa ser feito, é para validar alguma hipótese de algum problema que encontramos. Então aqui — de forma nada técnica — contamos o contexto, qual é o cenário, qual é a ideia ou hipótese e **o que se espera** com isso, com dados (qualitativos e quantitativos) do processo de discovery. ### OKRs relacionados Na InstaCarro somos orientados por OKRs, então qualquer ação que planejamos é para impactar algum deles. Basicamente listamos qual (ou quais) key results estão relacionados. ### O que precisamos e sugestões Aqui vamos um pouco mais a fundo. Essa parte é sempre um **convite para discussão**, é o pontapé inicial. Para facilitar, buscamos responder às seguintes perguntas: - Como é a jornada? (normalmente mapeada no RealtimeBoard) - São novas interações ou é uma interação em algo que já existe? - Tem algum comportamento especial? Como, por exemplo, alguma animação. - Tem tracking? São novos ou é para adicionar nos parâmetros existentes? - Tem interação com outras features? Impacta em algo? ### Critérios de aceite Como temos a jornada já desenhada, definir os critérios técnicos e também os critérios da experiência fica muito mais simples. ### Referências e recursos Basicamente, links de referência e assets. ## E tá funcionando? 