É 2012 e nossa equipe acaba de entrar no Airbnb. Estamos encarregados de construir uma experiência de “viagem social” para os viajantes da Airbnb. O pensamento é que os viajantes no Airbnb são espalhados pela cidade, e se facilitarmos que os hóspedes se encontrem e façam coisas juntos, as viagens da Airbnb seriam significativamente mais significativas. Trabalhamos muito e duramente para projetar uma experiência incrível para os viajantes descobrirem coisas locais divertidas para fazer com outros viajantes.
Avancemos para 6 meses depois quando lançarmos a V1 em São Francisco. O produto é bonito e as experiências são suaves. Adopção no entanto … nem tanto 📉. Uma pequena porcentagem de viajantes dá uma chance, e geralmente está tudo bem, mas está longe da reação que estávamos procurando. Nós iteramos um pouco, fazemos algumas melhorias incrementais, mas alguns meses depois terminamos e seguimos em frente.
Pessoalmente, tirei muitos aprendizados dessa experiência, mas acima de tudo, instilou em mim a importância de acertar a declaração do problema. Embora muitos fatores contribuam para a falha de um projeto, nada é mais certo para causar um projeto a falhar do que um mal-entendido do problema que você está resolvendo . No exemplo acima, reconhecemos tarde demais que o problema real que deveríamos ter resolvido não era “os viajantes querem sair com outros viajantes”, mas, em vez disso, “os viajantes querem encontrar coisas não turísticas de alta qualidade para fazer”. com outros viajantes é uma solução para isso, não o problema real. Felizmente, outro time reconheceu isso e acabou lançando uma solução muito melhor, Airbnb Experiences , alguns anos depois.
Como observei em meu último post , acredito firmemente que a definição da descrição do problema é o passo mais importante para solucionar qualquer problema. É enganadoramente fácil errar e, quando bem feito, é uma superpotência dos melhores líderes. Felizmente tudo o que é preciso é de três passos simples:
- Passo 1: Cristalize o problema que você está resolvendo
- Etapa 2: Alinhe o problema com sua equipe e as partes interessadas
- Passo 3: Continue voltando ao problema
“A verdadeira felicidade ocorre somente quando você encontra os problemas que você gosta de ter e gosta de resolver.” – Mark Manson
A Arte Sutil de Não Dar um F * ck
Um pouco de contexto primeiro
Essa estrutura é mais eficaz quando você tem um projeto em mente, seja um novo produto ou um novo recurso. Antes de mergulhar no design ou na engenharia, siga as etapas abaixo para definir seu projeto para o sucesso.
Se sua equipe não tem uma visão clara (ou seja, onde você está indo) ou estratégia geral (ou seja, como você chegará lá), faça uma pausa aqui e descubra essas coisas primeiro; isso , isso e isso vai ajudar.
Passo 1: Cristalize o problema que você está resolvendo
Comece respondendo estas perguntas sobre o seu projeto:
- Descrição: O que é isso?
- Problema: Qual problema é essa solução?
- Por que: Como sabemos que esse é um problema real e que vale a pena resolver?
- Sucesso: Como sabemos se solucionamos esse problema?
- Audiência: Para quem estamos construindo?
- O que: O que isso parece no produto?
Você também pode usar este prático modelo de 1-Pager . Eu acho que é mais eficaz se uma única pessoa faz a primeira passagem (geralmente a PM, mas não precisa ser). Abaixo está um pouco mais detalhadamente sobre a questão.
Descrição: O que é isso?
Esta é apenas uma breve descrição do que você está pensando, para que as pessoas que estiverem lendo este documento possam rapidamente entender o que é este projeto. Mantenha isso breve.
Problema: Qual problema é essa solução?
A declaração do problema em si é fundamental, então passe um tempo extra lá. Pense no problema como uma hipótese. O que você acredita que o problema que você está resolvendo é e por quê? Você adicionará mais contexto depois. Os principais atributos de uma declaração de problema forte incluem:
- É curto. Apontar para uma única frase para descrever o problema real. Quanto mais você precisar explicar, menos claro o problema acaba sendo.
- Está focado. Inclui apenas um único problema claro que pode ser de propriedade de uma única equipe e resolvido em um período de tempo razoável. Geralmente, é muito útil adicionar alguns exemplos do problema que você não está resolvendo.
- Refere uma “necessidade” que não está sendo cumprida. Tente se concentrar em torno de uma necessidade do usuário, mas também pode ser uma necessidade de negócios, se necessário. O framework Jobs-To-Be-Done é especialmente útil aqui.
- Inclui um quê e um porquê. O que está errado e por que isso é um problema? Você precisará fazer isso na próxima seção.
- É agnóstico de uma solução. Resista ao impulso de pular para uma solução tão cedo.
Exemplos de boas declarações de problemas:
- Os motoristas Lyft estão cancelando os passeios com muita frequência porque os passageiros estão muito longe.
- Os anfitriões da Airbnb estão se sentindo frustrados porque querem melhorar, mas estão achando difícil descobrir como.
- Os usuários estão caindo a uma taxa muito alta na etapa final do fluxo de inscrição.
Exemplos de declarações de problemas ruins:
- O crescimento do usuário está diminuindo. [Problema: Demasiado amplo para este processo, veja conselhos sobre como abordar a estratégia de grande figura aqui e aqui . Também não é centrado no usuário.]
- Construa um programa de fidelidade. [Problema: assume uma solução. Qual é o problema que isso está resolvendo?]
- Os usuários estão saltando do fluxo de inscrição. [Problema: não focado o suficiente, e perdendo uma hipótese do porquê. Vá um nível mais profundo.]
Por que: Como sabemos que esse é um problema real e que vale a pena resolver?
É aqui que você coleta evidências que apóiam sua declaração de problema, também conhecida como hipótese. O que inicialmente te convenceu de que isso era um problema? O que deixa claro para você que esse problema precisa ser resolvido?
Às vezes, nesta etapa, você percebe que esse problema não vale a pena priorizar agora, ou que precisa ajustar a maneira como pensa sobre o problema. Esse é o objetivo deste exercício, então não resista. Existem infinitos problemas para resolver – seu objetivo é se sentir confiante de que esse problema vale o tempo da sua equipe agora.
Algumas dicas para esta etapa:
- Olhe para ambas as evidências quantitativas e qualitativas. Colete todos os pontos de dados que apontam para isso como um problema real e importante.
- Qualidade acima de quantidade. Três a cinco pontos fortes de dados são muito melhores do que uma dúzia de pontos tangencialmente relacionados. O seu caso acaba sendo mais fraco com muitos itens, porque muitas vezes você acaba preenchendo-o com pontos de dados menores e não relacionados para parecer um monte de evidências. Seu estojo não precisa ser perfeito ou hermético.
- Jogue o advogado do diabo consigo mesmo. Tente se convencer de que isso não é realmente um problema real ou grande o suficiente. Que lacunas você tem em sua evidência? A evidência está realmente dizendo o que você pensa? Empurre-se aqui.
No final, será um julgamento entre muitos tradeoffs. Seu trabalho é fazer o melhor possível com os dados que você tem. Continue refinando a declaração do problema à medida que você aprende mais.
Sucesso: Como sabemos se solucionamos esse problema?
Você conseguiu o que planejou alcançar? Como você vai saber? Responda a essa pergunta e anote-a nesta seção.“Eu fiz isso ou não fiz isso? Sim? Não? Simples. ”- Andy Grove
Esse critério se torna incrivelmente importante em todo o projeto porque ajuda a tomar decisões e priorizar. O recurso X aumenta as chances de alcançar a meta que você definiu? Se não, corte.
Idealmente, essa é uma métrica específica, com um objetivo definido, que você pode medir facilmente. Idealmente, conecta-se diretamente aos KPIs da sua equipe. O ideal é que ele seja baseado em dados concretos sobre o tamanho da oportunidade, o tamanho do investimento e uma heurística de experimentos anteriores. Raramente é sempre ideal. Aqui estão alguns conselhos para definir seus critérios de sucesso:
- Tente fazer com que seja um número concreto, por exemplo, 10% de aumento em X, 50% de redução em Y, 20% de adoção do recurso Z em 3 meses.
- Escolha uma meta que seja crível, mas ambiciosa. Qual é o objetivo que, se você fosse bater, sua equipe e seus líderes ficariam animados?
- Se você não acha que uma métrica faz sentido para o seu objetivo (pense muito sobre isso), escreva o que concretamente seria o mundo se isso fosse um grande sucesso. Faça com que os critérios de sucesso.
Audiência: Para quem estamos construindo?
Isso é bastante autoexplicativo. Raramente deve ser para todos os seus usuários. É para usuários novos ou recorrentes? É para usuários casuais ou avançados? É para usuários no celular ou na web? etc.
O que: O que isso parece no produto?
É aqui que você tenta descrever a solução do problema. Dependendo da maneira como sua equipe opera e quanto já é conhecido, isso pode ser de nível muito alto ou muito detalhado. Na minha experiência, a chave aqui é alinhar com o (s) seu (s) designer (es) para descobrir o quanto eles querem e o que seria mais útil no processo.
Etapa 2: alinhe o problema com sua equipe e as partes interessadas
Você já viu aqueles outdoors Chipotle ao longo da rodovia (foto abaixo)? Anos atrás, meu colega de trabalho Peter apontou o truque por trás desses anúncios – cada um de nós está imaginando o nosso ideal e delicioso burrito ideal dentro daquele burrito de prata. Nós todos vemos o que queremos ver.
As declarações de problemas são como burritos de prata. Todos em sua equipe têm uma versão única do problema em suas cabeças. Às vezes eles são quase idênticos. Às vezes eles são muito diferentes. Quanto maior e mais complexo o projeto, mais provável é que sejam diferentes. Seu trabalho é erradicar esse desalinhamento cedo e com frequência. Abra o invólucro e verifique se todos concordam com o burrito dentro. Felizmente, temos um ótimo documento da Etapa 1 que facilitará seu trabalho 10 vezes.
Eu costumo abordar este passo da seguinte forma:
- Eu dou uma olhada no Passo 1 (mas, novamente, pode ser qualquer um em sua equipe que seja apaixonado pelo problema em particular)
- Compartilhe o rascunho com toda a equipe que estará envolvida neste projeto. Peça feedback (nos comentários, no e-mail ou pessoalmente). Integre o feedback e compartilhe novamente.
- Se o feedback está convergindo e a equipe parece alinhada, ótimo. Se não, puxe todos juntos e converse com discordâncias em pessoa.
- Depois que sua equipe estiver alinhada, compartilhe com seus stakeholders. É extremamente importante que sua equipe e as pessoas que avaliam seu sucesso estejam alinhadas com o problema que você está resolvendo antes de se aprofundar no design / eng.
- Reúna a equipe para um kickoff em pessoa, onde você analisa novamente a declaração de problema, responde a quaisquer perguntas pendentes e garante que sua equipe tenha tudo de que precisa para começar.
Passo 3: Continue voltando ao problema
O clássico clipe de Seinfeld abaixo, onde Jerry e Elaine tentam conseguir um carro que antes reservavam, é uma ótima metáfora para uma clássica armadilha no desenvolvimento de produtos.
Muitas vezes começamos com grandes intenções e alinhamento, mas quando isso é mais importante – quando o trabalho está sendo feito – muitas vezes não nos apegamos ao problema que resolvemos resolver. E essa é a parte mais importante do problema.
Há alguns anos, lembro de ter trabalhado em um projeto em que estávamos construindo um painel para os anfitriões da Airbnb. O problema inicial que definimos e alinhamos foi reduzir o tempo de resposta do host – diminuindo o tempo médio que um host levou para responder à mensagem de um convidado. Nossa hipótese era de que os hosts responderiam mais rapidamente se suas mensagens não lidas fossem mais proeminentes, e também foram lembrados de que o tempo de resposta afeta sua classificação de pesquisa. No final, tínhamos razão, mas durante todo o projeto, à medida que o escopo e a complexidade aumentavam (pro dica: painéis são um problema clássico do “burrito prateado”), tive de relembrar repetidamente à equipe o problema que resolvemos resolver. Nada ajuda a reduzir o escorregamento de escopo mais do que voltar à declaração do problema e às métricas de sucesso. Você pode resolver muitos problemas de várias maneiras, mas também pode criar um produto bonito que não resolve nenhum problema.
Evite essa armadilha com alguns bons hábitos:
- Em cada revisão de projeto, verifique se os designers começam analisando a declaração do problema. Se não estiver claro, pergunte: “Que problema estamos tentando resolver?”
- Em cada atualização de progresso para as partes interessadas, revise a declaração do problema para garantir que todos continuem alinhados com o resultado.
- Antes de finalizar os projetos, não deixe de se perguntar: “Estou me sentindo confiante de que isso resolverá o problema que resolvemos resolver?”
Uma nota final
Somos todos solucionadores de problemas profissionais – problemas técnicos, problemas interpessoais, problemas organizacionais etc. Você não vai escapar da solução de problemas.“Problemas são constantes na vida. Quando você resolve seu problema de saúde comprando uma academia, você cria novos problemas, como ter que acordar cedo para chegar na academia a tempo, suar como uma cabeça de mentira por 30 minutos em um elíptico, e depois tomar banho e trocar de roupa para o trabalho, para não estragar todo o escritório. Quando você resolve seu problema de não gastar tempo suficiente com seu parceiro, designando a noite de quarta-feira à noite, você gera novos problemas, como descobrir o que fazer toda quarta-feira que os dois não odeiam … Os problemas nunca param; eles apenas são trocados e / ou atualizados ”.- Mark Manson (
A Arte Sutil de Não Dar um F * ck )
Qualquer tempo gasto refinando sua habilidade de resolver problemas, em você e em sua equipe, é tempo bem gasto. Se você quiser levar isso ainda mais longe, há cinco livros que eu recomendo:
- Trabalho Profundo
- A Arte Sutil de Não Dar um F * ck
- Boa estratégia, má estratégia
- Meça o que importa
- Lean Analytics
Artigo de Lenny Rachitsky
