Product Field é um tipo de canvas que contempla basicamente o contexto em que um produto atua e o produto em si.

O playbook original com tudo sobre o conceito e como aplicá-lo pode ser encontrado no link abaixo:

The Product Field Reference Guide

Entretanto, este documento sintetiza quase tudo o que é preciso saber.

Esse vídeo (em inglês) também traz um bom resumo do todo:

Finalidades na Umbler

Toda vez que você encontrar um texto com uma linha preta (igual abaixo), trata-se de como utilizamos na Umbler (onde trabalho) o Product Field.

Embora o Product Field possa ser aplicado em diferentes contextos (produtos, momentos de produtos, etc), com o passar do tempo, começamos a utilizar o Product Field na Umbler para três principais finalidades:

1) Explicar o básico sobre um produto que já está rodando.

2) Auxiliar na escolha de tópicos a serem trabalhados nos ciclos.

3) Traduzir uma ideia ou um produto novo numa linguagem padronizada para dar o pontapé inicial de produtos e/ou projetos novos.

⠀

O canvas

O canvas em si, é composto por 12 áreas macro que podem ser combinadas com outras para expandir seu contexto de atuação.

A seguir, parte a parte explicadas.

Na Umbler, como explicado anteriormente, focamos no básico, para dar forma mesmo, serve mais para ter uma noção do que descrever em detalhes.

Isto, pois nossos produtos idealmente mudam bastante e manter listas de problemas e funcionalidades endereçadas por acabar se tornando improdutivo.

Então algumas descrições das áreas não são completamente honradas.

⠀

Product Core (zona interna do canvas)

No centro está o seu produto em si. No core de um produto inovador está a sua proposta de valor — a promessa específica para usuários e clientes. O core é dividido em uniqueness, problem, solution e competition.

Problem

Os problemas que impedem os usuários de buscar sua motivação, satisfazer suas necessidades e ter o progresso que desejam. Abordar problemas reais e relevantes é o que faz um produto ser verdadeiramente um produto. Uma descrição detalhada do problema serve como um guia para a solução.

• Quais os problemas fundamentais usuários em potencial encontram ao buscar sua motivação?
• Qual desses problemas vale a pena resolver?
• É realmente doloroso para os clientes em potencial ter esse problema?

⠀

Solution

A solução é como um produto resolve o problema dos usuários. Remove obstáculos, alivia dores, abre novas possibilidades e promove o progresso desejado. Uma solução pode ser muitas coisas, desde um serviço até um produto físico ou um processo comercializável. Descrevê-la em detalhes ajuda a obter uma primeira imagem clara do produto e determinar os recursos necessários para sua produção.

• Como a sua solução resolve o problema?
• Que tipo de produto, serviço ou processo é?
• Quais são seus principais componentes?

⠀

Uniqueness

A singularidade de um produto o diferencia (ou não) das outras alternativas, da competição. Uma clara diferenciação obriga os usuários a escolher seu produto em vez de outros e ajuda a quebrar seus hábitos. Ao descrevê-la em detalhes, você consegue verificar a força de sua proposta de valor e avaliar as perspectivas de seu produto para a adoção generalizada.

• Em comparação com soluções alternativas, o que torna seu produto único e superior?
• Quais recursos ou qualidades específicas farão com que os futuros usuários mudem seus hábitos?

⠀

Competition

As soluções ou comportamentos que você pode usar no momento para resolver ou contornar o problema em questão. Os usuários variam de produtos e serviços substitutos de acordo com hábitos, como preguiça, por exemplo. Tornar as alternativas explícitas ajuda a estabelecer uma referência para a singularidade do produto e desenvolver uma perspectiva realista sobre a adoção antecipada.

• Quais são as soluções alternativas que resolvem ou aliviam o problema?
• O que os usuários estão fazendo agora para resolver seus problemas?
• O que eles estão fazendo para ignorar ou contornar isso?

⠀

Product Context (zona externa do canvas)

Após entender o core do produto, é preciso lembrar que ele está inserido em um contexto maior, com goals, motivations, users, customers, distribution, production, enablers e drivers.

Goals

Os goals (metas) descrevem o que os desenvolvedores de um produto desejam alcançar com essa inovação. Podem ser metas de crescimento, proteção, reputação, mudança, sustentabilidade…

Na Umbler, acabamos optando por definir metas ousadas e com um horizonte de 3 a 5 anos. Além disso, destacamos o NPS de 60+ (provavelmente o maior do mercado) que hoje já foi atingido pelos produtos de hospedagem mesmo com o crescimento e mudanças de estratégia.

• Por que devemos investir nesse produto?
• O que devemos realizar?
• Qual o impacto no mercado?
• Qual alcance?

⠀

Drivers

Os drivers são as pessoas ou equipes mais responsáveis pelo resultado de um produto. Eles são responsáveis por dirigir e moldar o processo de inovação em busca dos objetivos estratégicos da organização. Para isso, eles precisam de certas capacidades e qualidades. Descrevê-los em detalhes, personalidade, competências, qualidades e papéis a desempenhar, ajuda a esclarecer os processos de tomada de decisão e detectar déficits de liderança.

• Quem são as pessoas ou equipes que estão conduzindo a inovação do produto?
• Quais qualidades eles têm e quais são necessárias para alcançar com sucesso os objetivos estratégicos?
• Falta competência, poder de decisão ou liderança?

⠀

Enablers

Os enablers são os recursos, ativos e pessoas (além dos drivers) que tornam possível a inovação de um produto. Portanto, sua disponibilidade é crítica para o sucesso da inovação. Descrever o que está disponível e o que está ausente ajuda a identificar os riscos e o potencial para uma inovação específica e dimensionar a capacidade geral de inovação de uma organização.

• Quais recursos e competências são necessários para criar o produto?
• Como seria o time?
• Quantas pessoas de cada área?
• O que está disponível?
• Existem oportunidades a explorar?

Na Umbler, o que é preenchido nos enablers nos ajuda a ter uma noção de como é o time (ou seria em novos times em formação) cobrindo tamanho, skills e, até mesmo, mindset.

⠀

Production

A produção é como a solução é construída. Pode incluir atividades físicas e virtuais, manuais, automatizadas e industriais, individuais e em equipe. Descrever esse processo ajuda a entender quais meios, habilidades e pré-requisitos são necessários para a produção e como é sua estrutura de custos.

• Quais atividades são necessárias para construir a solução?
• Que tipo de ativos de produção estão disponíveis?
• Eles são adequados para construir a solução?
• Quais habilidades, processos e parceiros são necessários?

Na Umbler, optamos por incluir aspectos técnicos e operacionais. Como você poderá perceber, os produtos da Umbler têm uma carga operacional relativamente grande, fruto tanto de aspectos tecnológicos (mexemos com infra, por exemplo) quanto dos nossos clientes, que geralmente são de dezenas de milhares.

⠀

Distribution

A distribuição significa levar o produto ao cliente. Isso abrange a atenção e aquisição do cliente, bem como a logística do produto. Eles são essenciais para o crescimento e o retorno do investimento.

• Quais canais, tecnologias e parceiros você pode usar para colocar o produto na mente e nas mãos dos usuários e clientes?
• O que é necessário para converter usuários ou clientes potenciais em clientes?
• Qual nível de consciência dos leads que o marketing vai focar?

Na Umbler, a distribution inclui públicos, níveis de consciência, canais e programas.

Customers

Os clientes são pessoas ou organizações que pagam para se beneficiar de um produto. Eles podem, mas não precisam ser usuários do produto. Descrevê-los ajuda a entender como as decisões de compra são tomadas, onde e quando podem ser alcançadas e quanto potencial de receita ou valor de vida útil representam.

• Quem são as pessoas ou organizações que realmente pagarão pelo produto?
• Por que eles vão pagar pelo produto?
• Como eles tomam decisões de compra?

⠀

Users

Usuários são pessoas que adotam e usam um produto para superar um problema específico enquanto buscam suas motivações. Descrever quem eles são e o que os diferencia ajuda a entender suas motivações e problemas, distinguir entre diferentes grupos e suas perspectivas e decidir como lidar com eles.

• Quem são as pessoas que usarão o produto?
• Como eles se comportam?
• Quais são seus traços?
• O que os torna especiais em comparação com outras pessoas?

⠀

Motivations

As motivações descrevem o que os usuários desejam alcançar. São as necessidades ou desejos a serem atendidos pela inovação. Torná-los explícitos fornece uma diretriz conceitual para o design e desenvolvimento e ajuda a rastrear o impacto da inovação sobre os usuários.

• O que os usuários desejam alcançar?
• Que ganhos eles desejam?
• Com que dores estão sofrendo?
• Que impacto a inovação deve ter sobre eles?

Conclusão

Por incluir tanto aspectos do contexto onde um produto atua quanto detalhes mais específicos do produto em si, o Product Field acaba sendo muito útil na hora de explicar ou esclarecer um produto.

Além disso, como é possível visualizar no guia de referência do Product Field, as diversas dinâmicas entre as áreas que formam o canvas podem servir como uma espécie de mapa na hora de identificar aspectos específicos, problemas, oportunidades e virtudes de um produto.

Assim, o Product Field pode ajudar muito times de produto em vários aspectos, tudo variando de acordo com o nível de aprofundamento e detalhe que se opta na hora de plotar o canvas. Pode ser que algo simples ajude a introduzir e dar uma visão geral para outras áreas ou pode ser que se prefira detalhar mais e, assim, entender as dinâmicas de maneira mais abrangente, ficando a critério de quem está utilizando a ferramenta.

Referências

• Post: Os 5 níveis de consciência dos consumidores na jornada de compra
• Livro: The Product Field Reference Guide

Product Field Canvas was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer: antes de continuar, saiba que o tempo de leitura informado pelo Medium está subestimado. Este artigo é longo e cansativo, bem como o método proposto nele. Trata-se de um resumo de mais de uma semana de trabalho, então, se você quer algo mais rápido e/ou mais do mesmo, não vale a pena continuar a leitura. Dito isto…

Motivação e contexto

Em 2018, a Umbler estava sob uma estrutura própria de times e desenvolvimento. Inclusive, meu chefe na época, Fábio Borges, escreveu um texto bem detalhado sobre esse modelo. Sob esse formato de trabalho, ele e eu fomos incubidos de rever a cadeia de valor dos produtos da Umbler para identificar oportunidades de inovação.

Basicamente, a provocação que deu início ao nosso trabalho foi:

“A Umbler resolve somente o problema da hospedagem”

Enquanto empresa de hospedagem, focávamos “apenas” na parte de fornecer a infraestrutura e configurações necessárias para que nossos clientes publicassem seus sites e emails. Além disso, estávamos revisitando algumas decisões sobre “ter um construtor de sites vs agências e freelancers devem ser sempre os criadores de sites”.

Nosso ponto de partida foi compreender melhor a maneira com que clientes finais e agências (ou freelancers, ou eugências, etc) trabalhavam. Para isto, conversamos com pessoas que recentemente haviam contratado serviços de criação de sites, social media, conteúdo, etc. Também conversamos com quem executou esses serviços. Tais conversas, que seguem os moldes do Teste da Mãe, são meu kick off favorito para qualquer iniciativa mais desestruturada.

Depois de várias horas em reuniões e inúmeros insights, eis que meu chefe anota uma conclusão que me deixou bastante perplexo…

Essa conclusão pode parecer um tanto óbvia num primeiro momento. Entretanto, se concordarmos com ela, estamos adimitindo que todas nossas iniciativas estão super restritas ao nosso repertório. Eu fiquei pistola com o que ele escreveu e parti para uma discussão.

Depois de algum tempo discutindo, tive um pequeno momento de brilhantismo. Percebi que para imaginar algo verdadeiramente “fora da caixa”, precisávamos de alguma estrutura que nos obrigasse a considerar coisas que não conhecíamos, coisas que não faziam parte do nosso conhecimento.

Agora, o desafio era encontrar um jeito prático de fazer isto. Pode parecer pouco, mas saber o objetivo, pelo menos para mim, já é um ótimo norte. Com isto em mente, parti para o Google.

As descobertas no Google

Passei algumas horas fazendo pesquisas e acessando os sites das primeiras páginas. A essa altura, eu já estava um tanto obcecado e utilizei todo meu tempo livre naquele dia procurando por uma resposta. E quando já não aguentava mais ler, decidi acessar os resultados em vídeo. Eu não me orgulho dos termos de pesquisa que escrevi, mas se serve como justificativa, já era mais de 1 hora da manhã…

“how to come up with outside the box ideas”

Até a data em que escrevo esse texto, aqui está, no segundo resultado, o vídeo que deu origem a tudo.

E como se não bastasse todo o tempo necessário para chegarmos até aqui, ainda temos esse vídeo de quase 14 minutos para assistir. Bom, eu fiz um disclaimer lá no início para alinharmos nossas expectativas 😅

É possível habilitar uma legenda em português traduzida instantaneamente no vídeo.

Os argumentos e as explicações do vídeo não poderiam estar mais alinhados ao meu sentimento e a minha conclusão…

Naturalmente, o palestrante, Giovanni Corazza, passa por uma série de conceitos e outros fundamentos sobre inovação, ambiente, empresas, hierarquia, etc. Mas vou focar no processo proposto no vídeo por meio do “experimento” realizado com a platéia.

Contudo, é possível perceber na palestra que essa parte dos tais “modificadores divergentes” passa um tanto batida. Pelo menos foi minha impressão quando assisti. Foi por isso que decidi ir um pouco além e pesquisar mais por “corazza divergent modifiers”.

Modificadores divergentes

A única fonte que encontrei até hoje sobre os modificadores divergentes é um artigo escrito pelo próprio palestrante da TEDx Talk. O nome do artigo é: “COUNTERPOINT AS A PRINCIPLE OF CREATIVITY: EXTRACTING DIVERGENT MODIFIERS FROM THE ART OF FUGUE”.

Como não tenho certeza sobre a distribuição do artigo, não vou deixar um link que redirecione diretamente para ele. Mas na data quando escrevo este texto, ainda é fácil de encontrá-lo na internet pesquisando pelo seu nome.

Embora seja importante ler o artigo, o pulo do gato é a aplicação de modificadores divergentes emaspectos comuns (ou óbvios) de uma solução conhecida, ou seja, de uma solução “dentro da caixa”. Entretanto, vale deixar claro que boa parte dos conceitos apresentados no conteúdo original foram abstraídos no processo que executamos e alguns, até mesmo, ignorados.

Lista dos modificadores divergentes

Extraídos diretamente do artigo, a lista dos modificadores seguidos de breves explicações feitas por mim.

Tradução: a tradução, nosso primeiro modificador divergente, fundamenta-se na tradução semântica de uma informação convergente. Mas não podemos nos restringir a idiomas, a tradução tem mais a ver com trocar o código ou a linguagem da informação inicial.

Exemplo: expressar um gráfico por meio de uma história em vez de números e um plano cartesiano.

Compressão: trata-se de comprimir o ponto de partida convergente. É importante pensar que não se trata exclusivamente de espaço, mas também de resumo.

Exemplo: resumir as informações sobre um resultado de pesquisa no Google (que aliás o Google faz na prática).

Expansão: oposto do modificador compressão. Novamente não é algo restrito a tamanho.

Exemplo: um disco, HD, de um máquina virtual que se expande automaticamente para receber mais arquivos.

Inversão: quando substituímos um elemento aceito, uma informação convergente, por seu oposto. Geralmente acabamos gerando um paradoxo ao aplicarmosse esse modificador.

Exemplo: a platéia assiste a peça pode ser invertido para a peça assiste a platéia. Vale ressaltar que existem dinâmicas onde pessoas da platéia são convidadas para participar de performances.

Embaralhamento: em inglês, shuffle. Nada mais que embaralhar a ordem dos elementos convergentes. Esse modificador é mais facilmente aplicável quando realmente estamos trabalhando numa ordem, mas ele não se restringe a essa aplicação.

Exemplo: No onboarding de um produto digital, o usuário informa seu email, cadastra uma senha, confirma o email, entra no produto e executa uma ação útil. Com o embaralhamento, o usuário entra no produto, executa uma ação útil e, caso tenha gostado, informa seu email, uma senha e, em outro momento, confirma seu email caso seja realmente necessário.

Sobreposição: para gerarmos uma nova perspectiva, introduzimos um elemento novo, geralmente oriundo de outro contexto.

Exemplo: aplicativos de realidade aumentada (PokémonGo, filtros de Instagram, tc).

Diminuição: trata-se de diminuir, geralmente de maneira exagerada, uma das informações convergentes. A diminuição pode ser em diversas dimensões, não restringindo-se a tamanho/volume.

Exemplo: diminuir o tempo de frete de compras online por meio de uma cadeia de logística que também abastece lojas físicas.

Aumento: esse modificador é o oposto do Diminuição.

Exemplo: aumentar o tempo de carregamento de um software para passar impressão de que ele faz mais coisas por baxo dos panos do que realmente faz.

Encenação: quando fazemos um elemento agir/comportar-se com as características de outro e vice-versa.

Exemplo: software e hardware podem trocar suas funcionalidades: hardware se torna soft (wearables) e software se torna hard (pré-instalados e “escondidos” nos objetos do dia a dia).

Reversão: facilmente confundido com inversão, mas tem outra proposta. A ideia desse modificador é ir de trás para frente no espaço, tempo, ação, movimento, etc.

Exemplo: em vez de explicar um conceito a partir do problema e desenvolver a solução, é possível apresentar a solução e fazer o caminho contrário até a identificação do problema.

Espelhamento: modificamos uma informação com se ela estivesse sendo vista num espelho, o que ficava na direira, fica na esquerda, etc. Não é um dos modificadores mais úteis, mas consta no artigo original.

Exemplo: um app que espelha os movimentos para se tocar um instrumento afim de ensinar tanto pessoas destras quanto canhotas.

Elemento aleatório: inclusão de um elemento completamente externo na tentativa de modificar o que temos por entendido do contexto.

Exemplo: transformar uma corrida de Uber introduzindo uma pizza em parte do processo. Assim poderíamos chegar no conceito do UberEats.

Remoção: removemos um elemento da informação convergente.

Exemplo: remover a necessidade de um servidor virtual inteiro quando queremos apenas rodar um trecho de código na nuvem (serveless functions).

Exemplo: transformar uma corrida de Uber introduzindo uma pizza em parte do processo. Assim poderíamos chegar no conceito do UberEats.

Finalmente chegamos ao fim dos modificadores divergentes. Segue uma listagem direta e simplificada para fins de observabilidade.

Tradução

Compressão

Expansão

Inversão

Embaralhamento

Sobreposição

Diminuição

Aumento

Encenação

Reversão

Espelhamento

Elemento aleatório

No vídeo do professor Corazza, o exemplo é de uma TEDx Conference. Vamos passar por esse mesmo exemplo para deixar o processo mais claro.

Exemplo das TEDx Conferences

Objetivo: Gerar novas ideias para TEDx Conferences.

Nota: Essa é um área bem conhecida para o público, assim trata-se de algo que há algum domínio sobre o assunto.

Informações convergentes (aquelas que fazem sentido para quem conhece o assunto):

• Bons palestrantes
• Um tema excelente
• Transições rápidas entre os palestrantes
• Um local adequado (palco e lugares para os espectadores)

Nota: Assim como dito no vídeo, a lista pode continuar. Um ponto que foi fundamental para o meu caso que descreverei mais adiante, foi não “encanar” no escopo e/ou no agrupamento dessas informações convergentes. Recomendo que você faça o mesmo, pois quando for partir para a dinâmica de aplicar os modificadores divergentes, será fácil identificar quais informações são úteis e quais não.

Aplicando modificadores divergentes: para cada uma das informações convergentes, aplicaremos um modificador divergente. Não há critérios para escolhermos os modificadores, é só pegá-los e aplicá-los. Para o exemplo, vamos passar pelos mesmos que foram apresentados no vídeo.

Bons palestrantes -> Remoção -> Criador da talk não apresenta

Um tema excelente -> Não abordado

Um local adequado -> Aumento -> Um estádio

Transições rápidas entre os palestrantes -> Não abordado

Passar apenas pelas informações divergentes isoladas é apenas parte do caminho. Caminho este que é o fora da caixa, onde as idéias não devem fazer sentido.

O produto do processo está na volta, na assimilação e reenquadração do que faz sentido.

Quando essas ideias voltam, já sofreram alterações irreparáveis fora da caixa.

No caso do vídeo: fazer as talks nos intervalos de partidas de futebol em estádios onde os palestrantes apresentariam, talvez em duplas, palestras desenvolvidas por terceiros.

Assim com o próprio palestrante explica, o julgamento de se a ideia é boa ou ruim não entra no mérito do processo. O verdadeiro objetivo é o nascimento de uma ideia nova oriunda da navegação de informações convergentes pelos modificadores divergentes.

De volta ao desafio da Umbler

Agora com os conhecimentos do vídeo e do artigo, elaboramos uma estratégia para usarmos os modificadores divergentes.

Os pontos de partida devem ser sempre informações convergentes, ou seja, questões que temos algum domínio. Assim, decidimos aprimorar e estruturar nosso conhecimento sobre todo o processo em que freelancers e agências trabalhavam, desde conseguir potenciais clientes até serem pagos por um trabalho.

Fizemos um pouco de pesquisa por dados públicos em materiais como o Panorama das Agências Digitais 2018, entre outros. Na sequência, estruturamos as considerações e os aprendizados oriundos das conversas que tivemos com quem fez esse tipo de serviço, bem como com quem consumiu.

Mais uma vez colocamos tudo no nosso Miro.

Estabelecendo as informações convergentes

Nós fundamentamos nossas informações em tudo aquilo que de fato aconteceu na vida das pessoas com quem conversamos. Procuramos basear tudo sempre em experiências passadas e não em opiniões, bem aos moldes do Teste da Mãe. Para esta iniciativa não foi diferente. Depois de algumas reflexões, estabelecemos estas seis grandes áreas:

1. Prospecção
2. Briefing
3. Proposta
4. Desenvolvimento do projeto
5. Manutenção do projeto
6. Pagamento

Em seguida, destacamos em cada uma das áreas as informações convergentes oriundas de nosso conhecimento, das conversas e de dados públicos. Não mostrarei exatamente cada parte, pois este processo rodou inteiro dentro da Umbler e contém bastante informações estratégicas. Mas para fins de exemplo, abaixo nosso entendimento (informações convergentes) sobre a área 3, a Proposta.

Com essas colunas em mãos, criamos uma matriz adicionando os modificadores divergentes. Escolhemos aqueles que batendo o olho já conseguíamos alterar uma informação convergente. Lembre-se, não se apegue muito na escolha dos modificadores, se estiver com muita dúvida, escolha todos os listados, mesmo que posteriormente não consiga utilizar todos.

Modificando as informações convergentes

Somando informações convergentes e modificadores divergentes, nossa matriz ficou completa. Contudo, vale ressaltar que levamos muitas horas para conseguir preencher cada célula com pelo menos uma informação modificada. Talvez não seja o caso para todo mundo, mas para nós geralmente as ideias boas surgem entre a linha tênue entre o cansaço, a empolgação e o sarcasmo.

Por falar em sarcasmo, enquanto sentíamos a obrigação de gerar pelo menos uma ideia por célula, diversas brincadeiras surgiram. Isto, pois volta e meia falávamos qualquer coisa, mesmo que sem nenhum sentido, simplesmente para preencher as células. Vou mostrar alguns exemplos das pérolas que escrevemos no nosso Miro.

E para dizer bem a verdade, num dado momento, ficamos preocupados com a quantidade de bobagens escritas. Até hoje acredito que sem grandes fundamentos e razão, acabamos por dar um voto de fé no processo. Lembro até mesmo de me conformar que era possível que o processo do professor Corazza fosse tão genial que estava além da minha compreensão. E nessa linha, eis que surge mais uma reflexão…

Soluções inovadoras geram resistência e ironia.

Lembra da imagem de uma “folha” com todas modificações de somente uma parte do processo que modificamos?

Esta é a visualização de todas as folhas…

Para honrar nossa crença de que soluções inovadoras geram resistência e ironia, decidimos plotar cada um dessas ideias modificadas (os post-its amarelos) em uma matriz com o eixo X “Quebrar a internet” e o eixo Y “Resistência e ironia”. Colocamos a dimensão de quebrar a internet pois nosso CEO mencionou algo nesse sentido em alguma reunião.

Com isso, chegamos na disposição abaixo.

Criando os protótipos inovadores

A partir de agora, o que nos restava era “apenas” criar protótipos inovadores a partir das informações modificadas. Para tal, priorizamos escolher itens com maior potencial de “Quebrar a internet” e “Geradores de Resistência e Ironia” e começamos a montar soluções que ainda respeitassem a ordem em que entendemos que estes trabalhos precisam:

1. Prospecção
2. Briefing
3. Proposta
4. Desenvolvimento do projeto
5. Manutenção do projeto
6. Pagamento

Naturalmente, a ordem seguiu como um guia onde seria possível ignorar uma parte pelo fato de ela não fazer sentido no protótipo (ex: Pagamento em um protótipo de produto free para sempre).

Embora minha intenção seja de compartilhar o máximo de informação possível sobre o processo e os produtos dele, preciso tomar cuidado para não relevar detalhes do que criamos e decidimos priorizar dentro da Umbler. Mas para fins de exemplo, vou separar uma das ordens que optei para guiar um texto (uma espécie de pitch) de um dos mais de 10 protótipos desenhados ao final do processo.

Resultados obtidos e o que esperar disso tudo

Na prática, de concreto, saímos do processo (que durou uma semana a contar do início das entrevistas) com mais de 10 protótipois para apresentar para nosso CEO e para demais stakeholders.

Entretanto, em um nível mais abstrato, acabamos por conhecer diversas outras soluções, segmentos e oportunidades. Além disso, executamos 3 MVP’s e, considerando um dos protótipos mais promissores, optamos por adquirir uma empresa que caminhava na direção dele. Dos 2 MVP’s restantes, um deles acabou evoluindo para um produto dentro da Umbler após várias iterações e modificações, obviamente.

Este último ponto sobre aquisição nos chamou bastante a atenção, pois acabamos conhecendo ferramentas muito similares aos protótipos que havíamos desenhado. Na prática, talvez nunca teríamos as conhecido sem o processo (ou pelo menos levado muito mais tempo).

Considerando que conversamos com as pessoas envolvidas no processo (freelancers, empreendedores, etc) numa segunda-feira e apresentamos os protótipos na segunda-feira da outra semana, acredito que tenha sido um processo cansativo, mas não muito fora dos padrões de design sprints, inceptions, etc. Além disso, decidimos muitos caminhos conforme íamos executando.

Sobre recomendá-lo para outras pessoas empresas e contextos?

Confesso que não tenho certeza sobre o potencial produtivo de passar uma semana fazendo isto. Entretanto, acredito que profissionais bastante experientes podem mitigar os riscos de todo o processo não dar em nada.

Para estabelecermos um parâmetro, eu era o profissional menos experiente e já tinha na época 7 anos de mercado, a maioria deles, todavia, enquanto desenvolvedor. Já meu par, o Fábio Borges, além de mais de uma década trabalhando em startups, é muito diferenciado em relação a processos, estratégia e design. Além disso, recebemos orientações de um colega ainda mais experiente com design (design raiz, estratégico, etc), o Thiago Fontella.

Entretanto, caso você sinta que precisa de novos horizontes ou que tenha uma ideia sobre produto, inovação e design lhe pertubando, penso que vale a tentativa. Afinal de contas…

Na média, as soluções de qualquer coisa são restritas ao “mundo” da pessoa ou grupo de pessoas que está criando aquela solução. Isso vale para a solução entregue pelos freelancers, mas também serve para nós que estamos criando essa solução aqui agora mesmo.

Depois de alguns anos como gerente de produto, percebi que há dois principais pontos para que tenhamos entrevistas produtivas com nossos usuários. Eles não são os únicos, longe disso, mas sem dúvidas foram os mais responsáveis pelo meu fracasso quando eu não os compreendia completamente.

São eles…

⠀

Focar nas partes importantes

Quando saímos do mundo das planilhas, do Google Analytics ou de qualquer outra ferramenta de métricas, precisamos interagir com esses humanos que utilizam nossos produtos. E acredite, esses humanos têm vidas complexas, jornadas cheias de detalhes e visões de mundo bastante únicas.

Assim, se não tomarmos as rédeas das entrevistas, elas facilmente viram conversas quaisquer que podem nos encher de dúvidas irrelevantes. Eu me recordo de fazer várias entrevistas improdutivas em função da minha incapacidade de focar e explorar os aspectos realmente importantes.

⠀

Entrevistar as pessoas certas

Há um trecho do livro “O Teste da Mãe”, de Rob Fitzpatrick, que acredito resumir muito bem a motivação por trás de se entrevistar as pessoas certas:

“A maioria das startups não morrem de fome, elas na verdade se afogam.”

A ideia dessa frase é a de que precisamos entender e ir atrás de um segmento bem específico de potenciais clientes em vez de acreditar que nosso produto é útil para todo mundo. Isto vale principalmente para produtos ainda em busca de seus primeiros clientes, mas não se restringe a esta fase.

O grande problema por trás disso é que nem sempre é fácil de identificar que estamos conversando com as pessoas erradas. Dependendo do tipo de produto em que trabalhamos, isto pode ser ainda mais complicado. Mas felizmente existem alguns sintomas que nos indicam que isto pode estar acontecendo:

1. Ficamos sobrecarregados de opções e não sabemos por onde começar.
2. Percebemos algum progresso, mas não conseguimos nos provar certos ou errados sobre nossas suposições.
3. Recebemos feedbacks misturados e não conseguimos ligar os pontos.

Customer Slicing ajuda, sobretudo, nessa segunda parte, na escolha das pessoas certas para conversarmos.

⠀

Customer Slicing

Customer Slicing é uma técnica utilizada para estreitar um segmento ao ponto de que as entrevistas e demais interações com os usuários tenham o máximo de produtividade possível. Esse nível de foco é super importante para que possamos aprender sobre nossos usuários com ritmo e profundidade adequados.

A primeira vez que li sobre esse conceito foi justamente no livro em que retirei a frase sobre startups se afogarem: O Teste da Mãe. A propósito, eu tive a honra de traduzi-lo para o português 😉

Voltando ao Customer Slicing…

Basicamente, precisamos partir de um segmento e “fatiá-lo” em grupos menores até que tenhamos um público bastante tangível com quem possamos conversar.

Para isto, devemos pensar no grupo inicial e fazer os seguintes questionamentos:

• Todos dentro desse grupo comprariam/usariam o produto ou só alguns?
• Por que esse subgrupo quer o produto? Qual o problema específico deles?
• Todos nesse grupo têm a motivação certa ou somente alguns?
• Que outras motivações estão por aí?
• Que outros tipos de pessoa têm essas mesmas motivações?

Podemos observar dois grupos de respostas onde o primeiro é uma coleção de dados demográficos e o segundo é um conjunto de objetivos/motivações. Entretanto, caso alguns dos grupos ainda fiquem genéricos, devemos continuar “fatiando-os”.

⠀

Como saber se o Customer Slicing foi bem feito?

Não precisamos terminar todas as entrevistas e gerar nossos insights somente para, então, sabermos se nosso processo foi bem feito. Na realidade, podemos seguir uma simples orientação.

Se não está claro para nós onde (geograficamente ou digitalmente) podemos encontrar esses usuários, então provavelmente não acertamos no Customer Slicing. Mas é importante lembrar que a parte geográfica não se restringe a cidades, estados, países, etc, podemos interpretá-la como: tipo de empresa, bairro, plataforma, redes sociais, entre várias outras possibilidades geográficas.

No caso de sentirmos que ainda estamos muito genéricos nessas definições, precisamos voltar alguns passos e fatiar nosso segmento inicial até que saibamos onde encontrar essas pessoas.

⠀

Onde e quando isto é importante?

Há alguns bons processos e contextos onde o Customer Slicing nos entrega bastante valor, quando:

• Estamos pensando em criar um produto ou serviço novo.
• Estamos planejando uma Design Sprint ou uma Lean Inception.
• Estamos executando pesquisa de UX ou de mercado.
• Estamos decidindo o tom e demais decisões sobre uma marca.
• Estamos tentando entender melhor uma oportunidade.
• Estamos tentando entender os Jobs To Be Done de um produto.

E vários outros cenários presentes na vida de quem trabalha com produtos, especialmente com produtos digitais.

⠀

Para dar sequência

Assim como quase tudo na carreira de produto, a prática e o estudo não levam à perfeição, mas nos deixam bem afiados. Colocar em prática o Customer Slicing, principalmente a parte de responder às perguntas que partem de um segmento, não precisa ser complicado. Uma hora ou duas, preferencialmente com mais gente, de discussões e reflexões devem gerar boas ideias e dar um ótimo norte para a próxima rodada de entrevistas.

⠀

Livros mencionados no artigo

• O Teste da Mãe
• Sprint
• Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo

Quer trocar uma ideia? Fique à vontade de me chamar.

Email · LinkedIn

O que é Customer Slicing? was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

A JTBD+ esteve no TDC Porto Alegre 2019 nessa sexta-feira. O Daniel apresentou o conceito de Jobs To Be Done e algumas dicas práticas para quem quer partir para sua primeira entrevista.

A palestra ocorreu na Trilha de Gestão de Produtos e foi apresentada no palco da Stadium. Você pode acompanhar o conteúdo na íntegra:

Jobs To Be Done para gestão de produtos - Daniel Salengue

Curtiu o conteúdo? Deixe seu e-mail pra receber novidades! 👇

TDC 2019 em Porto Alegre | 29/11/19 was originally published in JTBD+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Conversar, conversar, conversar…

Se você “é novo em Jobs To Be Done”, pode ser que ainda não esteja claro que conversar com clientes é central para a aplicação de Jobs To Be Done. Aliás, se por qualquer razão você se deparar com uma “abordagem de JTBD que não inclui em algum momento um contato com clientes, pode ter certeza de que você está no caminho errado.

Como Product Manager, tive a oportunidade de conduzir e auxiliar diversas conversas com clientes. Algumas tiveram o objetivo de identificar as Forças do Progresso e mapear a Linha do Tempo, outras se focaram em levantar pontos mais específicos. Independentemente de seus propósitos, com a prática ficou claro que conversas “bem feitas” podem revelar boas oportunidades, sobretudo, de inovação.

Entretanto, a parte “bem feita” é bastante crítica, pois assim como uma pesquisa bem feita pode revelar oportunidades, uma mal feita pode ser um tiro no pé. Isto, pois como diriam bons pesquisadores e inovadores como Rob Fitzpatrick e Alan Klement:

Na melhor das hipóteses, uma pesquisa mal feita pode ser uma grande perda de tempo, dinheiro e energia. Na pior, pode embasar decisões equivocadas.

A boa notícia é que há alguns fundamentos que, quando compreendidos e aplicados, aumentam muito as chances de sucesso de uma pesquisa por meio de conversas com Jobs To Be Done. Dentre alguns fundamentos que misturam prática, conceitos e trocas de conhecimento com a galera da JTBD+, separei três que agregam bastante valor na hora de conversar com os clientes.

1. A última vez é mais precisa que o costume.
2. O diabo está nos detalhes.
3. Não é feio forçar um pouco a barra.

A última vez é mais precisa e reveladora que o costume

Esse fundamento me recorda dos tempos de faculdade. Embora minha formação tenha sido muito técnica, tive a oportunidade de cursar disciplinas de administração e pesquisa de mercado. E sabe de uma coisa? Eu escutei muita bobagem sobre como conversar com clientes nessa época.

Mas talvez a mais equivocada de todas é uma que eu acredito que você já tenha visto em muitos trabalhos e, principalmente, em TCC’s: a pergunta sobre hábitos.

Você já viu perguntas formuladas da seguinte maneira?

O que você costuma fazer quando [determinada situação]?

ou

Você tem o costume de [fazer determinada coisa] quando [determinada situação]?

ou (talvez a pior)

Você costuma [alguma coisa extremamente genérica]?

O principal problema desse tipo de pergunta é a resposta que segue. Na maioria das vezes, essa resposta é uma bobagem, algo completamente hipotético que não deve ser considerado como boa informação sob hipótese alguma. Mas não pense que isto é má intenção ou simplesmente má vontade da pessoa com que você está conversando, o problema é que uma pergunta formulada desse jeito é extremamente convidativa para uma “simulação mental”.

Simulação mental = nos colocarmos ou fingirmos que estamos em determinada situação e, então, imaginarmos o que faríamos.

E, embora nós seres humanos façamos essas simulações o tempo todo, a realidade é que somos péssimos nisso. Adoramos dizer que temos autoconhecimento e que sabemos como agiríamos em determinado cenário ou, então, como seremos em determinado futuro. Mas, se você parar friamente para pensar, vai concordar que na maioria das vezes agimos diferente do que pensávamos.

É por esta razão que:

A última vez é mais precisa e reveladora que o costume.

Não fale ou formule perguntas com o verbo “costumar”, pergunte sobre a última vez que ele “[determinada situação]”. A seguinte estrutura vai lhe ajudar muito mais:

O que você fez na última vez que [determinada situação]?

A maior precisão vem do fato de que uma vez estabelecida uma confiança entre você e o cliente, é muito menos provável que ele minta deliberadamente sobre o que aconteceu nessa última vez. Em linhas gerais, é mais fácil e, até mesmo natural, mentirmos sobre algo que aspiramos (uma simulação mental). Entretanto, lembrarmos de algo que fizemos e, ainda sim, dizer outra coisa é um processo no mínimo mais custoso.

Enquanto isso, o caráter revelador se dá em função do contexto em que essa tal de “última vez” aconteceu. É comum termos preferência em resumir um costume em ocorrências mais agradáveis, o que prejudica o trabalho de pesquisa, uma vez que ele também se propõe a descobrir os desconfortos, situações e detalhes presentes na vida dos clientes e, principalmente, nos jobs to be done que eles estão tentando resolver.

Ah, falando em detalhes…

O diabo está nos detalhes

Quando se pensa em pesquisa, é comum acreditarmos que a formação de uma visão geral sobre o que estamos pesquisando é a coisa mais valiosa que podemos conseguir. Mas isto definitivamente não é verdade.

Visões gerais são importantes e também podem revelar aspectos importantes, mas raramente abrem caminho para inovação. Isto, pois em linhas gerais elas não descrevem a causa por trás das ações dos clientes.

E na realidade:

Saber o que o cliente fez e por que ele fez são as coisas mais valiosas que você pode descobrir por meio de uma pesquisa.

Então quando você for entrevistar um cliente a respeito “da última vez em que ele…”, procure os detalhes, principalmente quando o relato for diferente ou, até mesmo, inusitado. E sim, vai ser estranho fazer este tipo de pergunta e está tudo bem.

Uma pesquisa não se trata de uma conversa normal, você embora precise criar uma relação de confiança com o cliente, você não quer simplesmente “trocar uma ideia” ou falar sobre trivialidades, você quer saber as razões, muitas vezes escondidas, das escolhas e do comportamento dele.

Eu sou adepto de rabiscar a linha do tempo com eventos que o cliente relata para me orientar melhor. Desse modo consigo “ir e voltar” com ele por essas ocorrências e procurar por relações, sentimentos e outros detalhes. Além disso, anotar de alguma forma clara o que o cliente relata ajuda muito a encontrar contradições e retomar aos pontos que não fizeram muito sentido.

Contradições? Isto é algum tipo de interrogatório?!

Calma, mas…

Não é feio forçar um pouco a barra

Pois é, às vezes é necessário.

Quando você estiver conversando com um cliente é muito importante lembrar que você quer descobrir o que aconteceu e porque aconteceu. E não pense que isto é fácil de fazer, é muito comum criarmos uma empatia com o cliente e acabarmos mais “trocando uma ideia” sobre o produto como se fôssemos amigos. Falo por experiência própria que é natural fazermos isto.

E embora isto seja legal e, de fato, cria uma relação mais próxima com o cliente, não é para isto que formulamos uma pesquisa e, muito importante, estamos sendo pagos para fazer. Então mesmo que seja estranho, é bom pedir bastante detalhes sobre a experiência que o cliente teve.

Em linhas gerais, se começar a ficar estranho, pense numa boa desculpa, diga a ele, por exemplo, que é muito importante você saber as palavras que ele utiliza para descrever a experiência. Também é possível utilizar uma técnica que o Bob Moesta fala em seus workshops:

“Diga para o cliente que você tem a intenção de obter detalhes como se você fosse fazer um documentário ou um filme sobre a experiência dele.”

De fato os resultados que obtive por conversas com clientes foram muito melhores quando entendi e incorporei esses três fundamentos. Espero que lhe sirvam tão bem quanto serviram e servem para mim.

Dica extra

Tive o privilégio de traduzir um ótimo livro que incorpora muito bem esses detalhes 100% práticos sobre conversar com clientes. O nome do livro é O Teste da Mãe e está disponível na Amazon.

Fundamentos práticos para as conversas com Jobs To Be Done was originally published in JTBD+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quase sempre que converso com algumas pessoas depois de fazer alguma apresentação sobre Jobs To Be Done, alguém me pergunta algo parecido com:

“Ah, então esses jobs são tipo necessidades, certo?”

Então, eu respondo algo na linha de:

“É, mais ou menos, na realidade os jobs são necessidades descritas sob a perspectiva do contexto, dos clientes e da demanda…”

Pois é, referenciando “Rápido e Devagar: duas formas de pensar”, eu claramente preciso de uma resposta “rápida”, pelo menos para esse papo depois das apresentações.

Para a resposta comprida, preciso explicar que os jobs to be done surgem e tomam forma na vida dos clientes e têm relação com os produtos por meio do Sistema do Progresso.

O que é o Sistema do Progresso?

De maneira objetiva e prática, trata-se da aplicação do pensamento sistêmico na análise dos Jobs To Be Done. Quando falamos em jobs, é comum descrevermos suas características referentes às necessidades dos clientes e em como as descobrimos por meio de conversas (ou “entrevistas”) que utilizam a Linha do Tempo e as Forças do Progresso.

Mas quando o interesse é expandir a análise dos jobs to be done para definir estratégias, seja de marketing, produto, vendas, etc e/ou modificarmos o produto em si, entender as interdependências entre clientes, produtos, demanda faz toda a diferença.

Então, basicamente o Sistema do Progresso é um mapeamento que podemos utilizar para separar as diferentes execuções que pretendemos trabalhar.

As origens do Sistema do Progresso

Uma das primeiras descrições sobre o Sistema do Progresso foi apresentada por Alan Klement. Geralmente em suas apresentações o autor destaca a importância do pensamento sistêmico aplicado a Jobs To Be Done. Ainda de acordo com ele, o Sistema do Progresso é uma contribuição direta de Bob Moesta para a parte mais prática de Jobs To Be Done.

Na realidade, não é fácil encontrar materiais sobre esse assunto. O que diga-se de passagem é uma pena, pois essa ferramenta é muito útil para quem quer tomar ações a partir do que for descoberto.

O que quer dizer a palavra “Progresso” nesse nome?

A teoria dos sistemas e do pensamento sistêmico define que todo o sistema tem uma conexão entre todas as suas partes. Essa conexão, por sua vez, precisa ser algo diretamente ligado ao propósito do sistema.

No caso do Sistema do Progresso, clientes, produtos, produtores e demanda estão conectados pela necessidade dos clientes em ter progresso em suas vidas.

Esse progresso que os clientes querem em suas vidas é a cola que une as partes desse sistema.

As quatro partes do Sistema do Progresso

Dividir para conquistar, as quatro partes seguidas de suas respectivas explicações.

Um cliente começa pela flecha vermelha e segue no sentido horário, atravessando eventualmente o pontilhado branco. Esse ciclo representa as relações entre clientes, os jobs to be done, a demanda e os produtos.

Vamos ver, então, cada parte desse sistema.

Quer o progresso

Em relação às Forças do Progresso, aqui é onde o Push e o Pull atuam. Por alguma razão o cliente quer/precisa mudar. Numa perspectiva de progresso, ele deseja ser o que ainda não é ou poder fazer o que ainda não pode. Enquanto consumidores, nós queremos nos aproximar desse estado por meio de um produto.

Isto está diretamente ligado àquela frase bastante vendedora que você provavelmente já conhece:

“As pessoas não compram produtos, elas compram versões melhores delas mesmas” — algum vendedor e/ou profissional de marketing

É nessa parte do Sistema do Progresso que o job toma forma. Esse job está entre o cliente e o progresso que ele deseja.

Mas é claro, somente saber que é aqui que o job acontece não é o suficiente, afinal de contas, o que é acionável nisto?

O que deve ser feito aqui é descobrir em detalhes como esse job específico se formou. Há algumas perguntas a serem feitas sobre isto.

1. Quando o cliente percebeu que precisava mudar? Aconteceu alguma coisa específica?
2. Como ele percebeu que precisava mudar? O que ele estava fazendo/pensando?
3. Houve alguma mudança na vida do cliente? Hábitos? Estilo de vida? Algo do tipo?
4. O que havia de errado com a maneira com que ele resolvia esse job?
5. Existia diferença entre o que ele imaginava que deveria acontecer e o que aconteceu?

Pesquisa e escolhe uma solução

Com o sentimento de que não há progresso com a solução atual, o cliente parte para pesquisa e escolhe uma nova solução. Os problemas com o jeito atual de fazer o job estão mais definidos na cabeça do cliente. Além disso, diversas imagens e simulações desse cliente utilizando uma nova solução começam a se formar.

Nessa etapa do Sistema do Progresso, formam-se:

1. O que os clientes valorizam numa solução.
2. Como eles priorizam as alternativas.

Quando o cliente realmente começa a pesquisar e escolher uma solução, o que de fato é importante numa solução é revelado. Assim, fica bastante claro que que nem tudo o que dizemos ser importante realmente é.

É exatamente por isto que é tão importante entender o que realmente aconteceu (os fatos) na vida do cliente e como o critério de decisão surgiu. Nessa hora é importante levantar com os clientes o seguinte:

1. O que aconteceu na vida deles para que eles de fato começassem a pesquisar? Algo mudou? Por que começaram a pesquisar agora e não um mês atrás?
2. O que eles escolheram? Como eles imagina a sua vida durante e depois de utilizarem a solução escolhida?
3. O que eles diziam ser importante, mas a solução escolhida não tem?
4. Quais sãos as comparações que o cliente faz? Nem sempre os produtos competem com o que acreditamos.

Usa a solução

Eis que a nova solução é colocada à prova.

Mas é importante lembrar que somente os clientes revelam qual é a prova ;)

É comum os clientes utilizarem o produto de um jeito que você não imaginava. Então, é muito importante não presumir como os clientes estão usando a solução, mas sim levantar isto com eles.

Entretanto, é importante lembrar que o que está em jogo é a execução do job e não uma solução específica.

O quê?

Em muitos casos, a nova solução não é a ideal ou, até mesmo, resolve por si só o job. Aqui, é importante levantar também se o cliente está utilizando alguma combinação de dois ou mais produtos.

E lembre-se, o diabo está nos detalhes.

Não se trata de descobrir de modo generalista como o cliente está utilizando o produto e para que fins. É necessário saber os detalhes desse uso. Quanto mais detalhes, mais insights.

Então, perguntas como as seguintes merecem nossa atenção:

1. Como, quando e com quem o cliente usa a solução que escolheu?
2. Ele usa todas as funcionalidades dela ou só algumas?
3. Ele combina a nova solução com alguma outra, seja essa outra nova ou velha?
4. Ele se refere a solução como algo que você não pensava? Por exemplo, você chama sua aplicação de “plataforma de comunicação” e o cliente de “arquivo para salvar mensagens”?

Tem o progresso

Ou não.

É claro, se o cliente não obter o progresso que esperava com a solução escolhida, o sistema volta para a primeira etapa. Entretanto, um pouco diferente, é claro, afinal, alguma experiência a mais o cliente teve ao usar a solução escolhida.

Mas digamos que ele tenha o progresso, que as funcionalidades de fato resolvem o job que estava entre ele o que ele queria ser/fazer. Nesse ponto, o Sistema do Progresso revela como os clientes medem e verbalizam o sucesso com a solução.

Prestar atenção em como esse estado após a execução do job é descrito pelo cliente é muito enriquecedor. Nessa etapa, as seguintes perguntas precisam ser esclarecidas:

1. Os clientes obtiveram o resultado que esperavam? Como eles mediram isto?
2. O progresso que eles alcançaram está alinhado com o que eles imaginavam?
3. Há algum efeito colateral nesse progresso?
4. O que eles querem ser/fazer agora que já tem o progresso? Alguma nova oportunidade? Desafio?

O Sistema do Progresso é perpétuo

As pessoas são viciadas em progresso. Assim, quando nós atingimos o progresso que queríamos usando uma ou mais soluções, nós “desbloqueamos” outro objetivo, outro progresso que queremos atingir.

E esse novo progresso, ou melhor, essa nova oportunidade de fazer os clientes continuarem no sistema, é onde você pode pensar não mais somente enquanto produto, mas agora como empresa.

Se o seu produto para se manter enxuto se propõe a levar os clientes a um determinado progresso e, então, parar, a oportunidade de dar sequência no sistema pode ser pela empresa que faz o produto ou, então, parcerias.

O ponto é que algo ou alguém vai dar sequência no Sistema do Progresso.

A oportunidade enquanto empresa é a de criar produtos que continuamente entreguem progresso para o cliente.

Como os Jobs To Be Done surgem e tomam forma na vida do cliente? was originally published in JTBD+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quando pensamos em mapear ou definir concorrentes, uma das primeiras coisas que vem à mente são categorias.

“Que categoria será que esse produto se encaixa e quais são os outros players?” é um questionamento comum.

Em seguida, surgem as faixas de preço, possível público-alvo, features e por aí vai. Sendo assim, podemos dizer que nós “encaixamos” os produtos em possibilidades que geralmente se restringem a categorias e outras características gerais.

A partir desse mapeamento ou definição, muitas decisões importantes são tomadas. Preços, canais, personas, features, nomenclaturas, copy, etc são exemplos alinhados e dependentes de tudo isso.

O problema é que essa abordagem vai de encontro à perspectiva do consumidor. Eles, os consumidores, não pensam em categorias, características ou, até mesmo, no produto em si no que diz respeito à análise e cogitação de possíveis soluções. Na realidade, eles querem progresso em suas vidas diante de determinadas circunstâncias, em outras palavras, querem resolver um job to be done.

Concorrência com base nos Jobs To Be Done?

Visto que os jobs to be done são o que de fato os consumidores experenciam, será que não deveríamos identificar produtos considerados (ou utilizados) para um mesmo job como concorrentes? Independentemente de categorias e afins?

Para auxiliar nessa reflexão, vamos considerar o que acontece quando conversamos com clientes de algum produto seguindo a Linha do Tempo e as Forças do Progresso.

Geralmente quando fazemos isto, para não dizer sempre, muitas outras soluções ou “alternativas” aparecem na história do cliente. É comum descobrirmos um ou mais produtos muito diferentes daquele que estamos analisando.

Na prática, não é incomum encarar coisas como:

• Planilhas de Excel foram substituídas pelo Basecamp.
• Um estagiário foi contratado no lugar de um quadro no Trello.
• O Google Tag Manager acabou com os freelas terceirizados pela empresa.

Além disso, outro fato pesa sobre a questão da concorrência, o tempo e o dinheiro dos clientes são limitados. Quando alguém contrata um produto para um job, outras soluções são obrigatoriamente demitidas. Em linhas gerais, ninguém mantém dois produtos para o mesmo job.

Sabe aquela afirmação “nosso produto não tem concorrência, somos novos, estamos criando um mercado”?

Pois é, muitas vezes ela tende a ser equivocada. Isto acontece quando nos restringimos a analisar soluções de mesma categoria ou com funcionalidades parecidas.

Como veremos a seguir, alguns questionamentos e casos de uso reais podem elucidar esses pontos.

Quais os jobs to be done de um video game?

Essa é uma pergunta que o Bob Moesta já se fez.

Em uma de suas consultorias, Bob Moesta estava junto com seu time tentando entender mais sobre o “consumo” de video games.

Nessa pesquisa em específico, o público escolhido foi o de jovens adultos. A jusitificativa se deu de acordo com o histórico de gastos com jogos, essas pessoas são as mais rentáveis para a indústria de video games.

Experiente com Jobs To Be Done, o Bob Moesta conduziu a pesquisa em torno de mapear os jobs que essas pessoas tentavam resolver com video games. Com o tempo e algumas entrevistas, um job em específico começou a fazer sentido:

“Aliviar a tensão depois de um dia de trabalho estressante.”

Muito provavelmente você já você passou por isso e contratou alguma coisa para este job, não?

Quando se entende a concorrência como algo estabelecido pelo job e pelo cliente, muitas possibilidades se abrem. Na pesquisa conduzida pelo Bob, os principais concorrentes dos video games foram:

• Outras plataformas de video games (óbvio);
• Sorvete;
• Bebidas álcoolicas/happy hour;
• Yoga e outras atividades físicas parecidas.

Na sua opinião, essas soluções não lhe parecem adequadas para esse job?

Pois é.

Milkshakes de novo, é sério?

Você já teve a oportunidade de ver o vídeo do professor Christensen sobre Jobs To Be Done? Aquele com os milkshakes? Aquele que todo mundo fala a respeito quando o assunto é Jobs To Be Done?

Caso você não tenha visto e/ou não esteja muito entusiasmado para ver, o ponto é o seguinte:

A pesquisa apontou que grande parte dos milkshakes comprados num fast-food resolvem o job de “deixar a viagem de carro para o trabalho mais interessante e ao mesmo tempo garantir que a fome não comece muito antes do horário do almoço”.

Mas seguindo, no vídeo o professor deixa muito claro que:

“Na cabeça do cliente, os concorrentes do milkshakes não são os milkshakes de outras marcas, mas sim donuts, Snickers e bananas”.

Isto, pois a concorrência surge no contexto do job. Todos esses produtos diferentes são opções viáveis e que fazem sentido.

Em linhas gerais, é possível identificar esse concorrentes de outras categorias quando conseguimos focar nos detalhes da última vez que uma situação em específico aconteceu com o cliente entrevistado.

O que você faria se soubesse seus concorrentes?

Quando lidamos com a concorrência sobre a ótica dos jobs to be done é possível trabalhar de maneira bastante eficaz no produto e no seu marketing.

No exemplo da pesquisa sobre os video games, digamos que você trabalhe para a empresa dos consoles, o que você poderia fazer para destacar o seu produto frente aos concorrentes?

Destacar os benefícios exlusivos do video game diante da concorrência em vez de features e coisas do gênero pode gerar mais conexão. E não estamos falando de consoles de outras empresas.

Algo como “aliviar o estresse de maneira saudável”, pelo menos mais que álcool e sorvete, ou então criar jogos que simulem exercícios pode ser um caminho bastante promissor.

Além disso, esta abordagem não é nada convencional. Muito provavelmente os concorrentes não óbvios do seu produto não saberão fazer o mesmo, então a vantagem pode ser grande para o seu lado.

Há muito o que se explorar no que tange a concorrência mapeada e estabelecida sob as lentes dos Jobs To Be Done. A ideia aqui era trazer essa provocação à tona e destacar um pouco do valor que se pode gerar ao sairmos de alguns “padrões da indústria”.

Mas então, como você vê a concorrência considerando que os clientes têm recursos limitados e se importam mais com o progresso do que com os produtos?

O que Jobs To Be Done nos diz sobre concorrência? was originally published in JTBD+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

O podcast da JTBD+ vai trazer pra você reflexões e práticas sobre inovação, pesquisas com clientes e, é claro, sobre a teoria de Jobs To Be Done. O host, Pedro Vargas, vai contar com a participação de Daniel Salengue, Nicolas Martínez e Felipe Cardoso Barbosa na discussão de temas relevantes para o mercado e para a comunidade de Produto, UX e Design do Brasil.

Você pode escutar a primeira temporada nas seguintes plataformas:

• Spotify
• Google Podcasts
• Apple Podcasts
• Breaker
• Pocket Casts
• Radio Public

Se você não tem conta nas plataformas acima, escute de graça dando play nos episódios aqui embaixo. ;)

Trailer

Episódio #1

Episódio #2

Episódio #3

Episódio #4

Vídeo citado no episódio #4

Episódio #5

Artigo citado no episódio #5

Episódio #6

Episódio #7

Episódio #8

Episódio #9

Episódio #10

Episódio #11

Episódio #12

Envie sua pergunta ou sugestão pra gente para jtbdplus@gmail.com ou grave um áudio pra gente aqui: https://anchor.fm/jtbdplus/message.

Podcast da JTBD+ was originally published in JTBD+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Qual a relação entre gambiarra, inovação e Jobs To Be Done?

Quando estamos diante de uma situação/problema/job que precisamos resolver e, aparentemente, não temos um produto para nos ajudar, muitas vezes a criatividade vem à tona.

Certas vezes, essa criatividade envolve a combinação de um ou mais produtos que podem, ou não, desempenharem uma função diferente da qual eles foram projetados.

Essa frase anterior tentou explicar o que constitui, de maneira construtiva, uma gambiarra :)

Mas o que isto tem a ver com Jobs To Be Done?

No contexto de Jobs To Be Done, gambiarra e inovação estão ligadas à constância dos jobs.

Como assim constância dos jobs?

Então, jobs surgem nas vidas das pessoas e precisam ser feitos. Se eles estão presentes, as pessoas dão um jeito de os fazerem antes da existência de uma solução específica, certo?

Ou você acredita que antes da FedEx era impossível “fazer um pacote ir do ponto A até o ponto B”? Em outras palavras…

As pessoas sempre deram/dão/darão um jeito de fazer o job.

Essa constatação fica muito clara quanto conversamos com clientes sobre seus hábitos nos moldes das técnicas de conversa ensinadas em obras como O Teste da Mãe.

Percebeu aonde eu quero chegar? Se não percebeu, não tem problema, vamos seguir…

Digamos que diante de uma situação específica que surge na sua vida, você percebe que não há um produto (ou pelo menos você não conhece um) capaz de lhe ajudar.

O que você faz quando não há um produto para essa situação, para esse job?

Então, o que muita gente faz é utilizar um produto ou a combinação de mais produtos que não tinham bem essa finalidade necessária. Nesse cenário, eis que surge a gambiarra.

Só para linhar rapidamente…

Quando uso a palavra “gambiarra”, eu me refiro a todo aquele uso diferente da solução por parte do usuário, sabe? Quando o cliente usa o produto de um jeito que você não esperava ou, então, para um propósito que os criadores do produto sequer imaginavam.

Gambiarras merecem atenção

Principalmente de quem trabalha com produto.

Tudo é uma questão de avaliar bem o que está acontecendo para que a pessoa tenha escolhido fazer uma gambiarra para resolver seu problema. É claro, muitas coisas estão envolvidas nisto, às vezes não há nada de muito útil para ser descoberto. Mas esse pequeno risco pode valer muito a pena.

É importante ter em mente que nada disso é rocket science. Eu não tenho como argumentar com fórmulas que levem em consideração o tamanho da gambiarra, o esforço envolvido nela, a quantidade de ferramentas usadas em conjunto ou coisas do tipo.

Realmente é tudo muito relativo, mas se for ajudar, há quem diga que quando o comportamento (a gambiarra) for muito estranha, vale sempre a pena investigar.

Para ajudar, separei dois exemplos.

Gambiarra nas legendas do Youtube

Há pouco tempo, uu estava conversando com um colega de trabalho sobre palestras legais no Youtube. Em algum momento da conversa, surgiu a questão de que alguns desses vídeos são longos demais, o que dificulta nossa vida quando queremos encontrar apenas um trecho específico que nos interessa.

Foi, então, que esse meu colega me explicou a sua solução (gambiarra) para essa situação de querer econtrar um trecho do vídeo:

1. Acessar o video no Youtube (óbvio).
2. Clicar na opção “Mais…” que fica abaixo do vídeo.
3. Clicar na opção “Transcrição”.
4. Copiar a transcrição que o Youtube gera automaticamente (normalmente para as legendas) e colá-la num editor de texto.
5. Dar um “Ctrl + F” informando alguma palavra que você lembra do trecho que procura.
6. Ver onde a palavra foi encontrada e identificar o tempo em que ela foi dita.
7. Selecionar o tempo identificado no passo anterior.

É uma gambiarra, mas faz o job. Confesso que eu nunca tinha pensado nisto. Até então, eu realmente ficava pulando o vídeo e “chutando” onde mais ou menos se encontrava o trecho que procurava.

Mas o que dá pra tirar de insight dessa gambiarra?

No mínimo, dá para confirmar que existe o problema de “encontrar um trecho específico do vídeo”. E a partir daí, dá pra fazer bastante coisa, como, de repente, possibilitar uma pesquisa mais fácil no conteúdo do que é dito num vídeo. Possibilitar esse tipo de pesquisa seria algo inovador.

Gambiarra em parceria com Neymar Jr

Então, essa aqui na verdade teve bastante repercussão. Mas em resumo, foi o seguinte, um jovem começou a utilizar o Messenger do Facebook para armazenar links, tarefas, to-do’s, etc. Ele mandava mensagens para o perfil do Neymar Jr. Simples, não?

Esse jovem pensou mais ou menos o seguinte: “eu facilmente colo ali tudo o que quero armazenar e envio, afinal de contas, o Neymar nunca vai ler a nossa conversa, pois ele deve ter uma quantidade absurda de recados nas redes sociais”.

Mas o que repercutiu mesmo foi o fato de quem um dia o jogador acabou lendo as mensagens dele.

Nesse link aqui tem mais detalhes do ocorrido.

Mas o que dá pra tirar de insight dessa gambiarra?

Aqui a gambiarra é ainda mais interessante. Quando pensamos no Messenger, logo de cara podemos supor que o job é “conversar com amigos e conhecidos”. Tudo bem, o job principal pode ser esse mesmo. Mas o que essa gambiarra do jovem nos mostra é um job secundário para esse produto.

E não pense que isto foi muita criatividade do rapaz e que poucas pessoas fazem esse tipo de coisa. Vários aplicativos de mensagens estão incorporando jobs nesse alinha. Uma prova muito forte disto é a startup inovadora, Slack.

Aliás, o Slack é um ótimo exemplo, pois embora ele consista basicamente num aplicativo de mensagens, ele faz muito mais e, principalmente, sabe disto.

Fechando o link entre gambiarra e inovação

Lembra que comentei que as pessoas de um jeito ou de outro vão fazer o job?

Então, muitas vezes elas precisam fazer uma gambiarra pra isto. Só o fato de elas terem se esforçado para de algum modo conseguir resolver seu problema já indica que esse job é importante.

Na medida em que você entende esse job (seja ele conhecido ou não por você) através da análise do comportamento inesperado (a gambiarra) de um usuário, você pode ter bons insights para pivotar, alterar ou, então, criar um produto.

E se as pessoas faziam gambiarra é porque talvez não houvesse um produto melhor para isto, o que faz sua solução um tanto inovadora.

Para saber mais sobre o assunto

Acredito que o caso das gambiarras vale realmente muito a pena ser observado pelos responsáveis por um produto. Isto, pois elas se encaixam bem no caso de “comportamentos extremos”, assunto bastante explorado e importante.

Inclusive, essa é minha dica para dar sequência no estudo das oportunidades de inovação “escondidas” no comportamento dos usuários. Recomendo começar por este texto aqui: “Insights comportamentais são uma mina de ouro para o seu negócio”.

Uma gambiarra é muitas vezes a mãe da inovação was originally published in JTBD+ on Medium, where people are continuing the conversation by highlighting and responding to this story.

Quando pensamos em produtos extremamente bem sucedidos, parece que eles atendem a todos, não?

O Google permite que qualquer pessoa pesquise por qualquer coisa.

O Spotify permite que qualquer pessoa escute qualquer música.

O Evernote permite que qualquer pessoa armazene quaisquer anotações.

O Basecamp permite que qualquer time gerencie quaisquer projetos.

E por aí vai…

Mas quando estamos desenhando um produto, não é bem assim que as coisas funcionam. Se não tivermos foco, dificilmente vamos conseguir tomar decisões.

Recentemente, trabalhei na inception de um produto. Logo no início do processo, enquanto meus colegas discutiam o público alvo, lembrei da frase que escutei de Rob Fitzpatrick.

As startups em sua maioria não morrem de fome, elas se afogam.

Realmente a falta de foco é uma das principais razões que levam startups/produtos a falharem. Além disso, ela prejudica em diferentes pontos e momentos da vida de um produto ou de uma startup. Isto, pois essa falta de foco se trata mais de uma causa do que de um efeito.

Quando tentamos abraçar todas as pessoas e seus problemas, acabamos avançando poucos centímetros em várias direções, o que é exatamente o contrário do que um bom produto começa fazendo.

Nessa hora, uma das primeiras coisas que nos vêm em mente é aquele velho papo sobre nicho exaustivamente falado em milhares de materiais sobre produto, marketing e empreendedorismo.

Mas não é sobre isto que estou falando. Eu estou me referindo a algo com muito mais foco do que estabelecer um nicho, estou falando de Customer Slicing.

Uma breve explicação sobre Customer Slicing

Quando trabalhamos num produto, ainda mais no início, decidir com quem conversar (e aprender) é muito importante. O problema é que essa atividade geralmente não recebe a devida atenção.

É aqui que entra o Customer Slicing, uma técnica de funilamento de um nicho com o fim de deixar nosso entendimento sobre os clientes mais coeso e focado. A primeira vez que ouvi falar dessa técnica foi no livro o “Teste da Mãe” de Rob Fitzpatrick.

Para aplicar Customer Slicing, precisamos partir de um segmento (nicho ou seus clientes mesmo) e “fatiá-lo” em grupos menores até que tenhamos um público bastante tangível com quem possa falar.

Mas como fazer essas fatias na prática?

Precisamos, pensar no grupo inicial (pode ser nossos clientes) e, então, questionarmos sobre o seguinte:

1. Que tipo de pessoa teria mais interesse?
2. Todos comprariam/usariam o produto ou só determinadas pessoas?
3. Qual o problema específico dessas pessoas?
4. Todos têm a motivação “certa” ou só uma parte?
5. Há outras motivações além das pensadas inicialmente?

Depois de “rodar essas perguntas”, devemos nos questionar se está muito claro quem poderá ser parte desse grupo inicial de pessoas que podem realmente utilizar nosso produto.

E sim, estamos falando dos early adopters (o pessoal da faixa verde da imagem abaixo).

Essas pessoas com mais interesse, mais dor, mais energia, ou seja, mais razões para adotar uma solução deveriam ser nosso foco inicial quando estamos desenhando, idealizando, ou até mesmo construindo o MVP.

Você lembra dos produtos “extremamente bem sucedidos” do início do post?

Então, lá no começo…

O Google permitia que acadêmicos de cursos de computação encontrassem trechos de código.

O Spotify permitia que entusiastas do estilo indie escutassem músicas de artistas independentes.

O Evernote permitia que entusiastas de culinária armazenassem e compartilhassem receitas.

O Basecamp permitia que os clientes da 37Signals gerenciassem seus projetos de marketing.

Ou seja, essas empresas focaram muito no começo nas pessoas as quais realmente poderiam entregar valor.

Com o tempo, os produtos podem atender a mais pessoas

Como comentei no início do post, lembrei de Customer Slicing durante uma inception. De fato é importante estabelecermos esses critérios no início, pois vamos precisar de feedbacks mais pontuais e concisos desses primeiros clientes.

Aliás, receber feedbacks muito diferentes pode atrapalhar bastante. Quanto menos consistentes for a história que começamos a construir nas nossas cabeças sobre os clientes e suas visões de mundo, menos acionáveis são as coisas que conseguimos levantar. Esse limbo da pesquisa e dos feedbacks que não conseguimos transformar em produto é muito perigoso.

Mas é importante destacar que “expandir” a solução para mais casos e mais público é um caminho quase natural de produtos bem sucedidos. Com o tempo, depois de acertar com esse público inicial, a tendência é você expandir esse entendimento e essa maneira de “aprender” com os novos clientes.

De fato, cada etapa da curva de adoção do produto tem muito a nos ensinar.