Português (Brasil)
  • pensamento-do-produto
  • startups

Pensamento do produto em startups

Como determinar se é necessário desenvolver um novo recurso.

Guamian
Guamian
Product & Design

História por trás das cenas

Em 2021, mudei de trabalhar como designer de produtos em uma grande empresa para fazer parte da equipe de uma startup - Logto.

Aqui, lido tanto com o produto quanto com o design. Esse novo papel é uma mudança radical em relação à minha experiência anterior em uma empresa bem estruturada com processos claros e métodos de colaboração. Além disso, perdi meu colaborador mais próximo, um gerente de produtos. Consequentemente, tive que assumir vários papéis, incluindo produto, design, pesquisa, marketing e até mesmo gerenciamento de projetos.

Minha equipe e eu frequentemente nos encontramos imersos nas discussões mais desafiadoras, que geralmente giram em torno de implementar certos recursos do produto e definir seu escopo.

Nessas situações, todos nós nos envolvemos de forma apaixonada, expressamos nossas opiniões, com paixão e uma atitude opinionativa. Os pontos de vista parecem como uma poção gerada por uma máquina complexa - ao contrário do que é escrito nos documentos, eles carecem de organização e disciplina.

Isso ocorre porque a "intuição" geralmente surge antes da expressão estruturada, resultando em toneladas de discussões desordenadas, levando a batalhas filosóficas.

A motivação para escrever este artigo é organizar os princípios orientadores da tomada de decisões. Esses princípios derivam de minhas experiências pessoais e reflexões trabalhando no ambiente de uma startup, e não são uma solução mágica. Espero fornecer inspiração e perspectivas para outros empreendedores ou aqueles envolvidos em produto, engenharia ou design.

Este artigo é ótimo para leitura se você estiver na seguinte situação…

✅ Construir uma equipe de startup para desenvolver produtos de 0 a 1, juntamente com estratégias de GTM (Go-To-Market), especialmente para expansão internacional.

✅ Expandir produtos de 10 para 100 requer a criação de um roadmap de produtos.

✅ Líderes de produtos ou funções com responsabilidades de planejamento aprendem a identificar oportunidades prontamente.

✅ ICs aprendem a impulsionar novas iniciativas em grandes organizações.

Este artigo NÃO é ótimo para leitura se você estiver na seguinte situação…

❌ Projetos ambíguos iniciados de cima para baixo por líderes ou executivos.

❌ Projetos distantes dos objetivos de negócio com o intuito de validar o impacto individual ou da equipe independente.

❌ Demandas de produto altamente personalizadas focadas principalmente em grandes clientes.

Na maioria dos casos, devemos estar focados

Do ponto de vista absoluto, eu considero que manter o foco é senso comum, independentemente do tamanho da organização, pois os recursos são limitados.

Os recursos aqui não se referem apenas a recursos financeiros, mas também a tempo: em termos de tempo, tanto as equipes de startups como as grandes corporações estão em pé de igualdade.

Na maioria dos casos, devemos nos concentrar em criar recursos escaláveis e essenciais que se alinhem às necessidades dos nossos usuários alvo e às personas de clientes. O produto deve ser um "matador de dor" ao invés de uma "vitamina."

Ao manter o foco, torna-se mais fácil e natural sustentar uma proposta de valor de produto clara e aprimorar o entendimento do cliente. O produto avança de forma constante em direção à sua visão, expandindo gradualmente o espaço do problema de forma saudável, promovendo o crescimento orgânico.

Não temos que resolver todos os problemas; devemos manter nossa perspectiva e ser corajosos o suficiente para dizer não.

Então, vou escrever sobre diferentes tipos de "sinais" para se "esse recurso vale a pena ser desenvolvido."

Sinais superficiais

Este conceito, "sinais superficiais," representa sinais superficiais que podem servir como referências, mas ainda estão longe de tomar decisões.

Os concorrentes implementaram esse recurso

Enquanto recentemente tenho me divertido estudando ciência política, fazer comparações é um método semelhante à análise política, com o objetivo de obter "possibilidades." Ter essa perspectiva mais ampla pode oferecer insights, então, em nosso contexto atual, é significativo estudar vários produtos.

No entanto, se nos basearmos excessivamente na análise de concorrência, isso tende a levar a decisões de produto deficientes em pensamento estratégico. É essencial considerar por que um concorrente não implementou um recurso - ele não se alinha com seus valores, usuários alvo, prioridades estratégicas ou recursos?

  1. Não se alinha com seus valores
  2. Não se alinha com seu usuário alvo
  3. Recursos da empresa limitados, e existem muitos legados
  4. Não se alinha com suas prioridades estratégicas
  5. Claro, não tenha medo de considerar a possibilidade: Será que estamos pensando demais?

Portanto, a análise da concorrência deve fornecer informações em vez de tomada de decisão absoluta. É apenas parte do processo de coleta de informações para tomar decisões.

Usando deduções de cenários lógicos e subjetivos

As pessoas de produtos que são adeptas em entender as perspectivas do usuário e usar deduções de cenários podem verificar ou descobrir rapidamente novos cenários. No entanto, isso é apenas uma hipótese e requer mais trabalho em um ambiente real de go-to-market.

Embora deduzir cenários plausíveis seja valioso, confiar apenas nessa abordagem pode levar a criar um produto "tudo-em-um" ou incômodo antes de alcançar o ajuste do produto ao mercado, tornando as iterações e ajustes subsequentes desafiadores.

Uma analogia simples é tratar cada cenário usuário deduzido como um projeto de startup de 0-1, considerando mini estratégias de go-to-market, trazendo perspectivas de marketing e fazendo perguntas difíceis. Essa avaliação multidimensional vai além das necessidades do usuário e da experiência.

Feedback do usuário de alta frequência

Frequentemente, o feedback do usuário de alta frequência torna-se um princípio orientador para o desenvolvimento de recursos e o design de produtos. No entanto, esse princípio orientador pode ser uma armadilha às vezes. À medida que cresço e trabalho em mais projetos, estabeleço esse tipo de estrutura para lidar e lidar com o feedback do usuário,

  1. Defina o problema e o reenquadre de maneira louca e repetidamente

    Este processo envolverá muita deliberação, idas e vindas e debates, exigindo algum tempo e esforço. Não pense que esse processo é inútil, porque através das discussões, ele se divergirá e descobrirá alguns problemas de "iceberg". Minha equipe e eu costumávamos discutir sem fim sobre o certo e o errado de algo e soluções potenciais, o que não é bom. Agora, estamos mais em sincronia em identificar onde cada um de nós sente os problemas e focamos na resolução de problemas. Este processo é de alto valor.

  2. Opinativo vs. Não opinativo

    É super necessário definir se este recurso/cenário deve seguir uma abordagem opinativa ou não opinativa. Por exemplo, Notion é um produto opinativo; Google Docs é meio opinativo; Microsoft Word não é opinativo. Para um construtor de SaaS que visa inovar o antigo paradigma, é melhor seguir a abordagem opinativa. Os produtos opinativos dividem e filtram os usuários, e aqueles que concordam com eles são entusiásticos em expressar seu apoio. Isso é extremamente útil para ajudar o produto em estágio inicial a encontrar usuários iniciais e criar uma narrativa fácil de entender.

    Se você seguir uma abordagem opinativa, tente resolver o problema com uma única solução por cenário. Se surgir uma solução alternativa (Solução B para um dado Cenário A), verifique se a Solução A realmente aborda os pontos de dor. Se não, vamos revisitar a Solução A em vez de simplesmente introduzir outra solução.

    Os princípios do produto Intercom inspiraram esta abordagem: "Construir um produto que seja opinativo por padrão, mas flexível por dentro."

  3. Reconheça que os usuários podem sugerir trabalhos avançados a serem feitos

    Alguns usuários podem propor o uso de um recurso destinado ao cenário A para resolver o cenário B. Identificar essas armadilhas é crucial; não invista energia excessiva em problemas indignos.

    A única situação que merece atenção é quando a solução B indica uma necessidade real, não apenas uma alternativa à solução A. Isso significa que a solução B aborda um "problema recém-nascido" intimamente relacionado à visão e missão do produto. Este sinal é valioso quando a empresa quer crescer mais e descobrir sua próxima fase de expansão significativa.

Sinais ruins

Este recurso complicará o produto

Evitar complicar um produto não é sobre ignorar a resolução de problemas desafiadores, mas é um lembrete de que reconciliar um produto "complexo, abrangente" com uma experiência "simples, amigável para o usuário" é irreal no mundo real. Se você ignorar como tudo funciona junto (pensamento de sistema) e apenas se concentrar na correção de problemas de experiência do usuário fragmentados, o resultado é um produto mal projetado.

Produtos complexos desencadeiam uma reação em cadeia, dificultando o autoatendimento e prolongando o tempo necessário para perceber o valor no produto.

A criação de ferramentas para empresas (2B) é meio filosófica: envolve a criação de modelos mentais em conjunto com os usuários e o estabelecimento de uma estrutura que possa antecipar o comportamento do usuário. A complexidade geralmente surge de arquiteturas inconsistentes e desestruturadas, tentando satisfazer demandas juntando interações, resultando em produtos que são "sobrevivencialistas", ao invés de proporcionar excelentes jornadas dos usuários.

Os recursos que tornam um produto complexo, desde o requisito até a solução, são todos sinais ruins.

Embora isso não possa definitivamente ajudar você a dizer não, é um ponto crucial que exige compensações claras.

Este recurso prejudicará o posicionamento e a narrativa do produto

Em outras palavras, a criação de recursos que não se alinham com o posicionamento de um produto danifica e borra a imagem do produto. Por exemplo, Logto é uma ferramenta de desenvolvedor focada em gerenciamento de identidade no momento. Se eu disser, vamos construir um recurso de ferramenta de marketing, essa é uma má estratégia.

Este recurso consome recursos significativos, mas é difícil avaliar e perceber os benefícios

Esta perspectiva deriva do objetivo de negócio de uma empresa ou organização. Eu vi muitas atividades sendo feitas em um ambiente empresarial ou de grande corporação, tais como:

  1. Estabelecimento de uma plataforma de dados para melhorar a eficiência da engenharia.
  2. Criação de um modelo de previsão de crescimento anualmente, todos os anos.
  3. Tentativa de alteração de marca de um produto maduro.

Em um estado de operação relativamente estável, esses cenários são valiosos e devem ser encorajados e apoiados. No entanto, em ambientes de startup desafiadores, tais projetos exigem recursos significativos e tempo para validar o valor, indicando um compromisso com a busca profissional e não o sucesso dos negócios. Este ponto destaca um conflito entre as buscas pessoais, as crenças da carreira e os objetivos comerciais.

Enquanto iniciar projetos de forma proativa é admirável, também é importante reconhecer que a dedicação excessiva a algo pode não trazer retornos que valham a pena: usando meu martelo para encontrar pregos, depois usando uma régua para medir quão profundas são minhas cavidades e quão grande é meu raio— isso pode não ser crucial no grande esquema das coisas. Na realidade, a pessoa que me contratou para pregar pregos apenas precisa de uma maneira de pendurar uma foto, e eu não preciso provar o quão habilidoso eu sou em pregar.

Sinais bons

Alinhamento com a visão e roadmap do produto

Este ponto abstrato, mas vital, pode ser concretamente avaliado: ao considerar um recurso, pergunte se os usuários ficariam significativamente decepcionados se o produto não o tivesse, potencialmente fazendo com que eles saíssem.

Por exemplo, considerando o posicionamento atual do nosso produto Logto para resolver problemas de autenticação, autorização e gestão de usuários/organizações. Quanto mais um recurso estiver relacionado a esses aspectos, maior será sua prioridade. Se o Logto não tivesse um recurso específico, o quão decepcionados nossos usuários estariam? Se a resposta for sim, sugere que a prioridade é alta e é nossa missão proporcionar uma excelente experiência para o desenvolvedor para esse problema.

Validação suficiente ou hipótese clara

Silicon Valley enfatiza frequentemente a pesquisa do usuário e o dimensionamento da oportunidade por sua praticidade e rigor. Esses dois aspectos indicam que um recurso vale a pena explorar e desenvolver quando proporcionam insights positivos.

"Por que não?"

Esse conceito implica na fruta baixa que traz uma grande quantidade de alegria e benefícios sem esforço, tornando-a parte da personalidade e da marca do produto.

Este recurso representa inovação

Em meio a toda a análise, o pensamento racional é essencial, mas deixar espaço para a intuição também é crucial. Se você está convencido que um recurso é o futuro, apesar de não ter dados racionais ou validação de mercado, vale a pena explorá-lo.

Outras características ambíguas? Mantenha-o na fase de pesquisa e exploração.

As outras características indistintas, deixe-as desenvolver e nós podemos observar os "sinais" ao longo do tempo naturalmente.

Equilibrar a mente aberta e o pensamento crítico em um ambiente de rápida movimentação

Ao longo do desenvolvimento do produto, do empreendedorismo e das entrevistas de emprego para produtos, você pode encontrar muitas perguntas instigantes, especialmente no Vale do Silício, como o tópico que mencionei acima, devemos construir este recurso?

Embora esses tipos de perguntas possam não ter princípios universais, eles exigem execução cuidadosa e deliberação em situações concretas. Porém, quebrar perguntas grandiosas e vagas em respostas tangíveis é uma habilidade que os construtores refinam ao longo de suas carreiras e um superpoder para construir grandes produtos.

Espero que os insights fornecidos possam inspirar sua abordagem ao pensamento do produto em uma startup. Na Logto, valorizamos muito a construção de produtos que os desenvolvedores amam. Estamos felizes em conversar e compartilhar nossas perspectivas sobre tópicos semelhantes.