Construindo produtos com opiniões

Todo mundo gosta de uma pessoa que é tão teimosa em suas crenças que ela não cede a ninguém que discorda. Ok, talvez essa não seja uma afirmação universalmente verdadeira. Mas acompanhe-me enquanto aplicamos isso aos produtos SaaS.

Muitas startups (e especialmente empresas maduras) tanto falham em começar quanto lutam para manter o foco em o que estão tentando construir. É simplesmente tão fácil perseguir objetos brilhantes, se desgastar com reclamações, almejar a expansão para novos verticais antes que o vertical atual esteja feliz, ansiar por novos usuários que talvez quase possam se interessar pelo que você tem a oferecer (especialmente se a liderança que segura as cordas da bolsa forçar eles a usá-lo… cha-ching?).

O problema aqui é simplesmente que você não pode construir para todos. Ou talvez mais precisamente, você não pode construir um produto que as pessoas querem usar se você não estiver direcionando um tipo específico de pessoa com um conjunto específico de necessidades.

A resposta curta e doce: tenha opiniões e construa um produto com opiniões com essas opiniões em mente. Porque quando você não constrói com opiniões, você é deixado para construir com as opiniões de todos os seus usuários existentes e infinitamente potenciais — ao mesmo tempo.

Vamos mergulhar em quão doloroso pode ser construir para todos e, depois disso, vamos subir as 4 etapas da escada para construir um produto com opiniões.

Os contras de construir para todos

Algumas, até muitas, das pessoas dentro de “todos” terão boas ideias sobre o que você deveria estar construindo. (Não siga suas palavras exatas muito de perto.)

O problema aqui é que essas pessoas não vão concordar. Eles virão de diferentes origens, terão perspectivas diferentes, acreditarão que problemas diferentes são os problemas que precisam ser resolvidos, considerarão solucões diferentes como sendo certas ou erradas ou úteis ou frustrantes.

Em resumo: pessoas diferentes querem coisas diferentes, e portanto, não é possível construir uma boa experiência para absolutamente todos.

Você pode certamente tentar construir para todos. Na verdade, eu apostaria que você já está fazendo isso. Mas se/quando você seguir por esse caminho, todos e tudo sofrem.

O produto sofre

• Superlotação de recursos — parabéns, você é uma fábrica de recursos
• Experiência do usuário comprometida — acomodar todos esses recursos e opções é difícil, e a UX é a primeira a sofrer com o conjunto sempre crescente de capacidades
• Bugs… bugs em todos os lugares — os muitos recursos disparados e entrelaçados não vão se mesclar facilmente, e quando eles não o fizerem, pode ser um problema exponencial que se apresenta como uma quantia significativa de problemas reais
• Dificuldade em integrar com outros produtos — quanto mais complexo o produto se tornar, mais considerações precisarão ser tratadas ao tentar se ligar a outra ferramenta

Então o produto não é tão legal, e há uma enorme quantidade de pessoas que precisam lidar com tudo isso também…

A equipe sofre

• Dificuldades em coletar feedback de usuários [Produto] — mesmo que você esteja falando com vários usuários por semana, é difícil saber o que você precisa priorizar a construção quando todos querem algo diferente
• Pesquisa e testes de usuário ineficazes [Design] — você não pode destilar aprendizados que se apliquem a uma ampla faixa da base de usuários se essa base de usuários não for coesa
• Dívida técnica em todos os lugares [Engenharia] — sempre haverá dívida técnica, mas quanto mais funcionalidade, mais problemas você terá que deixar em segundo plano (enquanto isso, quando você se move em uma direção mais focada, os problemas tendem a convergir)
• Aumento da necessidade de assistência [Suporte/Sucesso] — seja através de documentação, chatbots, pessoal de suporte ao vivo ou reuniões semanais com empresas clientes, tudo isso leva tempo e recursos que poderiam ser melhor utilizados em outro lugar
• Foco distraído [todos] — a equipe passará um percentual muito alto de tempo apoiando recursos que poucos usuários se importam
• Metas ambíguas [todos] — sem um público claro, rapidamente se torna difícil alvejar os objetivos e métricas certos — ganhar todos os usuários possíveis (não importa o quão ruim o ajuste) conflita facilmente com manter os usuários felizes, bem como com a construção em direção à visão

Com todo esse sofrimento, não parece legal para o negócio…

A receita sofre

• Perda de clientes — quando os usuários não sentem que você está construindo para eles, seus olhos começam a se voltar para soluções potenciais que se importam mais com eles e suas necessidades
• Falta de uma proposta de valor clara — se seu produto não resolver um conjunto claro de problemas, então os prospectos não terão uma ideia clara (ou interesse) em o que você está vendendo
• Falta de diferenciação — apertar esse botão “leve meu dinheiro” é um enorme ponto de atrito, e é ainda mais difícil chegar lá se os prospectos não estiverem convencidos com o que estariam comprando — o que estão obtendo com seu produto que não podem obter em outro lugar?
• Diluição de marca e identidade — usuários diferentes com diferentes problemas precisam ser comercializados de maneiras diferentes — sim, você pode ter páginas de destino diferentes para palavras-chave e termos de pesquisa diferentes, mas qual é a mensagem principal, e ela ressoa com todos que você está direcionando?
• Estratégia de preços e pacotes complicada — usuários diferentes podem ter apetites diferentes para determinados pontos de preço — você pode pacotar perfeitamente partes do produto para agradar a tantos personas diferentes?

Não são apenas os negócios que estão sentindo a dor. Mais importante, há as pessoas para quem isso tudo supostamente é para…

Os usuários sofrem

• Curva de aprendizado íngreme — o onboarding se torna um assunto de dias, semanas ou até meses
• Dificuldade em encontrar e obter valor — a maioria dos usuários usará apenas uma fração da funcionalidade que você está oferecendo, então as necessidades específicas de um determinado usuário estarão efetivamente escondidas dentro de uma montanha de recursos
• Produtividade reduzida — mais recursos significa mais cliques de mouse significa fluxos de trabalho mais lentos significa tempo perdido
• Falta de suporte — em um ciclo hilário (?), quanto mais complexo o produto, maior o suporte necessário — mas isso não escala — então o resultado é documentação incompleta ou não atualizada, caminhos de chatbot circulares que perdem tempo enquanto fornecem pouco ou nenhum valor, ou até opções de suporte cortadas com ninguém para enviar um e-mail e opções removidas para conversar com representantes de suporte

Em outras palavras, você acaba construindo um software que pode fazer qualquer coisa… mas boa sorte em fazer qualquer uma delas.

Então, construir para todos não funciona (pelo menos, não se você quiser um produto útil, escalável e agradável). Mas você também precisa de usuários pagantes para que sua empresa seja bem-sucedida. O que você deveria fazer?

A resposta: construir um produto com opiniões.

Como construir um produto com opiniões

1. Tenha uma visão

Primeiro, você precisa ter uma opinião central para seguir no primeiro lugar — sua visão de produto

Esta visão deve orientar todas as decisões que você tomar mais tarde. Faça-se as seguintes perguntas:

• Estamos nos concentramos em abordar os pontos de dor cobertos pela visão?
• Este recurso nos ajuda a nos aproximar da visão?
• Se decidirmos perseguir este projeto, ele nos leva por um caminho que conflita com a visão (ou pelo menos não a suporte)?
• Estamos priorizando o trabalho na lista de tarefas com base no que fornece o maior valor em alinhamento com a visão?
• Estamos alocando recursos de uma maneira que prioriza a execução contra a visão?
• Estamos perdendo a visão?

Lembre-se, a visão do produto pode mudar — mas a visão é a visão até que você a mude explicitamente.

2. Escreva seus princípios

Em seguida, você precisa de princípios de produto para se forçar a construir da maneira “certa” (onde você define o que é “certo”). Você provavelmente já tem essas crenças na sua cabeça, mas é hora de escrevê-las para que toda a equipe possa se alinhar a elas.

Você poderia se basear em uma miríade de princípios — mas escolha aqueles em que acredita no seu (produto) núcleo. Para alguma inspiração, aqui estão alguns exemplos do que estou falando aqui — use, modifique, ignore ou adicione conforme achar adequado:

• A UX nunca deve atrapalhar — os usuários não devem ter que gastar uma quantia indevida de tempo lutando com a ferramenta para fazer o que querem
• A UI deve ser rápida — aplique a regra de 100ms
• Momentos de alegria quando possível (mas não muito) — os usuários devem sorrir quando usarem a ferramenta, mas não vá tão longe que o produto pareça tão pouco sério que perde credibilidade
• Projetado para equipes remotas — bem-vindo à era pós-Covid
• Empurre (não puxe)) atualizações em tempo real — os usuários nunca devem ter que apertar o botão “Atualizar”
• Intuitividade e ajuda embutida sobre documentação — a maioria das ações que um usuário pode tomar deve ser autoexplicativa; quando necessário, forneça dicas; a documentação deve ser um último recurso
• Configuração sobre personalização — permita que os usuários modifiquem certas maneiras em que o produto funciona, sem permitir níveis de personalização tão altos que as configurações se tornem mais complicadas do que a própria ferramenta
• Reduza a carga cognitiva — reserve o espaço na tela para o que importa
• Nunca seja chamativo — tosse como a maioria dos produtos implementa IA tosse

Ter os princípios certos do produto manterá você honesto. Você pode dobrar quando necessário, mas quando o fizer, você precisa escolher conscientemente para fazê-lo.

3. Escolha um persona de usuário (ou alguns relacionados)

Terceiro, seja muito específico sobre o persona de usuário para o qual você está construindo seu produto.

Isso pode parecer fora de ordem para você — afinal, você não deveria ter uma visão para o que está construindo se você não sabe quem usaria tal produto — você nunca chegará ao MVP se estiver tomando essas decisões sem pensar e conversar com usuários. Mas deixe-me explicar.

Eu incorporei uma (não declarada) suposição, antes da etapa 1, de que você já tem uma ideia do que problemas está resolvendo e para quem. A intenção aqui não é dizer-lhe como idealizar o que construir — isso é talvez um tópico para outro artigo. Em vez disso, o ponto desta etapa 3 aqui é fazer com que você hiperfoque em um tipo específico de usuário para construir. Você não deve construir para todos, e você não deve construir para um grupo enorme de pessoas completamente diferentes, também.

Então, vamos nos concentrar:

• Concentre-se em usuários que sentem as dores que você deseja abordar
• Concentre-se em usuários que já concordam com e acreditam na visão
• Concentre-se em usuários que apreciarão seus princípios
• Concentre-se em usuários que estão descontentes com as soluções existentes, ou pelo menos entendem que há um caminho melhor através de sua visão
• Concentre-se em usuários que podem e vão obter valor de cada etapa iterativa que você dá em direção à visão
• Concentre-se em usuários que estão dispostos a pagar por uma solução para seus problemas

Tudo isso se resume a: Concentre-se em usuários que concordam com suas opiniões sobre o que vale a pena construir e como construí-lo. Se você tiver que gastar tempo persuadindo usuários potenciais de que sua solução é boa para eles, você está começando sua jornada de produto em uma grande desvantagem.

Nota: Por suposto, se você chegar ao final deste exercício e descobrir que não tem ninguém (ou um grupo tão pequeno de usuários que seu TAM é muito pequeno para sustentar um negócio), você pode precisar revisitar suas opiniões. Se você se encontrar nessa situação, reflete sobre sua visão e seus princípios — há algo aí que está cortando um grande mercado que você poderia (ou talvez deveria) estar focado? Eu não estou dizendo para você sacrificar seus valores, mas se houver um desalinhamento completo, seu produto não terá sucesso.

4. Priorize

Por fim, priorize como você vai iterar em direção a essa visão sua. Isso parece óbvio, mas no mundo real, é mais fácil dizer do que fazer.

Algumas regras importantes a seguir à medida que você prioriza:

• • Priorize o trabalho que fornece o maior valor para o persona de usuário específico que você está direcionando — você só pode construir uma (ou poucas) coisas por vez
  • Quebre os recursos em sub-recursos que possam ser entregues independentemente e, em seguida, priorize cada (sub)recurso contra todos os outros (sub)recursos — é fácil cair em uma armadilha de recursos que nunca se sentem concluídos, então tome o tempo para ficar à frente disso desenhando uma linha na areia onde você parará de trabalhar em um recurso e se mover para o próximo
  • Reconheça que os recursos são limitados — não importa quanto você queira construir tudo, você não pode — trague essa pílula de verdade antes que seja tarde demais

Priorização implacável

•  — se algo não estiver contribuindo para a visão, pule-o, e se algo não fornecer

suficiente

 valor, depriorize-o
• Seja ciente do viés de recência — não priorize o problema do último usuário com quem falou; agregue os resultados de todas as suas entrevistas com usuários
• Não construa exatamente o que os clientes pedem — eles estão (quase sempre) errados — mas, é claro, ainda considere priorizar suas necessidades subjacentes
• Priorize a remoção de recursos que não fornecem mais (ou inesperadamente nunca forneceram) valor — remover a funcionalidade pode ser tão vantajoso quanto adicionar funcionalidade, se essa funcionalidade estiver causando mais mal do que bem

Tudo isso se trata de foco, foco, foco. Você não sabe por quanto tempo terá, mas você tem uma janela de tempo limitada para ser a solução para seus usuários. Se você perder essa janela, você será superado por alguém mais. Priorize para vencer.

Em resumo

A jogada geral aqui é encontrar um grupo de usuários que já concordam com suas opiniões, e que, portanto, já querem o produto com opiniões que você está construindo.

1. Visão: tenha opiniões sobre o que você deseja construir em direção
2. Princípios: tenha opiniões sobre como você deseja construir o que está construindo
3. Persona(s): encontre pessoas quem concordam com suas opiniões
4. Priorize: tenha opiniões (que evoluem à medida que você aprende mais) sobre quando você se concentrará em componentes individuais do que você está construindo

E, é claro, usando tudo isso, construa seu produto com opiniões.

Se parecer que você está fazendo mais convencimento do que confirmação quando fala com usuários, você terá uma batalha difícil pela frente. Mas se houver uma platéia existente que já está pedindo o que você está vendendo (mesmo que eles não percebam isso ainda), você realmente tem algo.

Acredite em suas opiniões e encontre usuários que acreditem nelas também. Em seguida, construa sem medo.