Só a ponta ainda não é uma adaga

Em meados de 2025, demos um novo produto a um grupo de usuários beta.

Antes de lançá-lo, eu já sabia que não era bom o suficiente.

Sua interface carecia de polimento, as interações ainda não pareciam naturais e o fluxo funcional estava incompleto. Pudemos ver muitos dos problemas sem esperar pelo feedback do usuário. O mais preocupante é que estes problemas não podiam ser separados uns dos outros. A interface, a experiência do usuário, a integridade funcional, a confiabilidade e a capacidade de manutenção tiveram que funcionar ao mesmo tempo antes que pudessem formar um produto completo.

Mas tínhamos acabado de passar meses absorvendo um conjunto de métodos de inicialização: conhecer os clientes antecipadamente, avançar em pequenos passos e iterar rapidamente. Portanto, embora estivéssemos insatisfeitos com o produto, ainda acreditávamos que deveríamos lançá-lo primeiro.

Os usuários levantaram rapidamente muitas questões. Já conhecíamos uma parte considerável delas antes do lançamento. O feedback deles se tornou o ponto de partida para a mudança que fizemos na segunda metade do ano.

Olhando para trás, aquele teste beta dividiu 2025 em duas metades. Durante o primeiro semestre, continuamos construindo MagicGourd, na esperança de fazer sua magia finalmente aparecer. No meio do ano, extraímos uma ideia do Sayso, construímo-la rapidamente e a colocamos na frente dos usuários. No segundo semestre, em vez de continuar buscando a velocidade de lançamento, passamos a desenvolver as capacidades de nossos produtos. O ponto de partida para tudo isso veio no início do ano, quando recebemos investimento da MiraclePlus e aderimos à sua aceleradora.

Até o final do ano, ainda não havíamos feito aquela adaga. Mas começamos a entender: uma ponta por si só não é uma adaga.

Uma entrevista que eu não planejava participar

No início de 2025, eu não tinha planos de arrecadar dinheiro.

Em 2024, passamos a maior parte do nosso tempo construindo MagicGourd e lançando 27 versões. Nossas tentativas limitadas de arrecadação de fundos não levaram a lugar nenhum, e o produto ainda estava longe do “verdadeiro segundo cérebro” que imaginávamos. Mas gostei muito do processo de construção.

Achei que poderíamos continuar em uma escala muito pequena, avançando um passo de cada vez, sem pressa em fazer investimentos.

Kehan me fez mudar de ideia. Ele me disse que captar investimento não precisava ser apenas uma questão de dinheiro. O acelerador da MiraclePlus, seus mentores e seus ex-alunos também poderiam nos ajudar por muito mais tempo.

Até então, o prazo de inscrição já havia expirado. Mas eu não queria desperdiçar a recomendação de Kehan, então enviei uma inscrição de qualquer maneira, descrevendo brevemente como pensei sobre um verdadeiro segundo cérebro.

Esta entrevista ocorreu no escritório MiraclePlus em Pequim. Enquanto esperava, vi diversas sugestões de entrevista em uma tela: as respostas deveriam ser simples, diretas e verdadeiras.

Na entrevista do ano anterior, eu havia inconscientemente procurado as respostas que os investidores queriam ouvir. Quando desafiaram repetidamente as nossas ideias, fiquei preocupado com a possibilidade de as minhas respostas não serem suficientemente boas. Como eu respeitava as pessoas do outro lado da mesa, poderia até começar a duvidar do meu próprio julgamento.

Desta vez, não estava com tanta pressa.

Depois de um ano inteiro de desenvolvimento em 2024, ainda estávamos na água, mas não estávamos mais lutando como tínhamos logo após entrar. Eu simplesmente disse o que realmente pensava.

Dr. Lu Qi perguntou o que eu achava de SenseTime. Disse que, antes de mais nada, estava profundamente grato à empresa, pois ali passei por um período crucial de crescimento e transformação. Perto da chegada do ChatGPT, o SenseTime pode ter demorado um pouco para responder porque um navio grande é difícil de virar. Mas em 2025, pude ver que isso estava mudando rapidamente e acreditei que uma era melhor para SenseTime estava chegando.

Ele então perguntou o que eu achava de DeepSeek. Minha resposta foi uma palavra: custo. Eu não elaborei na época. Eu simplesmente acreditava que o custo afetaria diretamente a escala em que uma tecnologia poderia entrar no mundo real.

A entrevista foi mais tranquila do que eu esperava. Talvez porque eu não estivesse mais desesperado por um determinado resultado, ficou mais fácil falar com simplicidade.

Depois, MiraclePlus investiu em nós e aderimos ao acelerador.

Queríamos que a magia finalmente aparecesse

Se o objetivo de 2024 tinha sido fazer primeiro a cabaça, no início de 2025 queríamos que sua magia finalmente aparecesse.

Em 2024, mantivemos um foco muito claro e concluímos a versão 0.27 do MagicGourd. O produto ajudava as pessoas a marcar o que as tocava em páginas da web, PDFs online e vídeos, registrar os pensamentos que surgiam e preservar tudo isso ao longo do tempo.

Mas ainda estava mais perto de um contêiner. Poderia coletar e gerenciar os registros de uma pessoa, mas não poderia entendê-los verdadeiramente, muito menos ajudar alguém a descobrir pensamentos que permaneceram inacabados.

Portanto, quando planejamos para 2025, estabelecemos para nós mesmos uma meta muito maior. Não ficaríamos mais satisfeitos em adicionar recursos. Queríamos dar um verdadeiro passo em direção ao verdadeiro segundo cérebro que havíamos imaginado.

Queríamos entender os registros de longo prazo de uma pessoa, encontrar conexões espalhadas por diferentes épocas e diferentes conteúdos, entender o que o usuário estava pensando naquele momento e reconhecer intenções que ele ainda não havia expressado claramente.

O objetivo era emocionante. Também estava muito além do escopo que podíamos gerenciar na época.

Durante o primeiro semestre do ano, dedicamos um enorme esforço ao desenvolvimento. O problema não era a falta de trabalho duro, mas a quantidade de coisas que precisavam ser resolvidas de uma vez. Cada passo adiante expôs mais questões. O escopo continuou se expandindo, enquanto nosso ritmo de desenvolvimento continuou desacelerando. Meio ano se passou e ainda não havíamos colocado o valor mais importante diante dos usuários.

Depois de entrar no acelerador MiraclePlus, continuamos ouvindo uma palavra: sharp.

Meu mentor no acelerador, Peter, nos disse repetidamente que uma startup deveria fazer uma adaga, não um canivete suíço.

À medida que o primeiro semestre do ano chegava ao fim, começamos a pensar que o problema era que o produto havia se tornado muito grande. Se não pudéssemos construir um verdadeiro segundo cérebro de uma só vez, deveríamos extrair seu elemento mais importante e transformá-lo em um produto que fosse pequeno, rápido e legal.

Na época, pensávamos que era isso que uma adaga significava.

Um segundo cérebro deve entender as intenções ainda não ditas

Perguntamos repetidamente o que era mais importante em um segundo cérebro.

A resposta que finalmente encontramos foi compreender a intenção.

Uma ferramenta de informação comum geralmente começa com o que o usuário já inseriu. Se um usuário escrever uma frase, ele poderá revisá-la. Se o usuário fizer uma pergunta, ele poderá responder. Se o usuário salvar um artigo, ele poderá resumi-lo.

Mas muitas intenções humanas não são claramente expressas no início. Às vezes, temos apenas uma vaga sensação de que algo é importante, sem saber com o que realmente nos importamos. Às vezes estamos prestes a conhecer alguém importante e temos muitas informações em mente, mas não sabemos o que vale mais a pena dizer. Às vezes, sabemos o sentimento que queremos expressar, mas não conseguimos encontrar as palavras certas.

Se um segundo cérebro pudesse combinar o contexto atual do usuário com essas intenções não expressas, faria mais do que processar as informações existentes. Ele começaria a participar do processo pelo qual uma pessoa forma uma expressão ou julgamento.

Com base nessa ideia, concebemos um produto chamado Sayso no meio do ano.

Usando o contexto atual da pessoa, o produto a ajudaria a ver o que poderia dizer a seguir. Não queríamos que a IA decidisse a verdadeira intenção do usuário. Queríamos que ela oferecesse possíveis direções nas quais o usuário pudesse reconhecer o que realmente queria expressar.

Essa necessidade aparece em muitas situações reais. Antes de conhecer uma pessoa importante ou iniciar uma conversa importante, muitas vezes as pessoas não têm falta de coisas para dizer. O problema é saber qual parte de uma grande quantidade de informação é mais importante naquele momento.

Sayso tentou comprimir o grande objetivo de compreender as intenções implícitas de uma pessoa em uma tarefa concreta: usar o contexto atual da pessoa para descobrir intenções que ela ainda não havia expressado.

Pensamos que finalmente tínhamos encontrado uma adaga dentro da vasta ideia de um segundo cérebro.

Confundimos “Pequeno” com “Afiado”

No meio do ano, nós passamos de um produto grande para um pequeno e nossa velocidade de desenvolvimento aumentou visivelmente.

Mas durante essa mudança, nossa compreensão de uma adaga ainda estava limitada à sua forma externa.

Pensamos que tornar o produto menor o transformaria em uma adaga. Achamos que menos recursos o tornavam uma adaga. Mais tarde, também confundimos novidade e velocidade de desenvolvimento com precisão: se um produto parecia novo, podia ser construído rapidamente e chegar logo aos usuários, parecia mais próximo da resposta certa do que o canivete suíço que estávamos construindo.

No meio do ano, construímos o Sayso em um tempo muito curto e o entregamos aos usuários beta.

O feedback mostrou que algumas pessoas realmente precisavam de ajuda para se expressar antes de uma reunião ou conversa importante e conseguiam compreender o valor de descobrir intenções a partir do contexto. Isso ofereceu evidências iniciais de que o problema que buscávamos resolver era real, e não apenas uma ideia que parecia nova.

Mas o produto em si não funcionou.

Um demo de IA sobre compreensão de intenção talvez só precisasse produzir um resultado surpreendente em alguns exemplos cuidadosamente preparados. Um produto real tinha que mostrar aos usuários qual contexto fornecer, ajudá-los a entender por que oferecia sugestões específicas e permitir que editassem, escolhessem ou rejeitassem essas sugestões de modo natural.

A interface tinha que inspirar confiança. As interações não poderiam criar um novo fardo. Os recursos deveriam apoiar o usuário durante toda a tarefa. Ao mesmo tempo, o sistema tinha que ser confiável e fácil de manter e melhorar.

Nenhuma dessas coisas, tomadas individualmente, estava necessariamente além de nós. A dificuldade era fazer com que todos fossem bons o suficiente ao mesmo tempo, dentro de um período limitado.

Os usuários conseguiam identificar os problemas rapidamente, mas não conseguíamos resolvê-los ao mesmo tempo com rapidez e qualidade. Às vezes concluíamos um recurso às custas da experiência geral. Às vezes melhorávamos uma parte da experiência e tornávamos o sistema subjacente mais difícil de manter. Às vezes a capacidade principal já podia ser demonstrada, mas o usuário ainda não conseguia completar uma jornada inteira sem problemas.

O teste beta não foi sem sentido. Pelo menos permitiu-nos confirmar que a necessidade existia.

Mas a existência de uma necessidade não significa que um produto funcione. Um produto funcional não significa que um mercado funcione.

Como a qualidade da implementação estava entre os usuários e o valor central, não testamos realmente se Sayso poderia fornecer esse valor de forma consistente, muito menos se um número suficiente de pessoas gostaria de usá-lo ao longo do tempo.

Talvez tivéssemos visto o problema que a adaga deveria perfurar, mas ainda não tínhamos a capacidade de transformar esse insight em uma adaga que alguém pudesse realmente usar.

O olho podia ver, mas a mão ainda não conseguia fazer

Depois de lançar Sayso, inicialmente atribuímos o problema à velocidade de iteração insuficiente. Os usuários nos deram feedback, então a resposta parecia continuar avançando em pequenos passos e mudando o produto mais rapidamente.

Mas logo descobrimos que a velocidade não era o único problema.

Antes de lançar o produto, já sabíamos que ele não era bom. Muitos dos problemas no feedback do usuário não excederam nosso próprio julgamento. O que nos faltou não foi o olho para distinguir um produto bom de um produto ruim, mas a mão que pudesse rapidamente transformar esse julgamento em um produto.

O olho já podia ver. A mão ainda não conseguiu fazer.

Isso não significa que tudo o que aprendemos sobre os produtos em 2024 estava errado.

Ao longo de 2025, MagicGourd permaneceu online e mantido. Novos recursos chegaram mais lentamente, mas o serviço existente continuou funcionando. No final do ano, MagicGourd tinha cerca de 3.000 usuários e o feedback permaneceu positivo em geral. Não tínhamos conhecimento de nenhum dado de usuário perdido ou corrompido durante o ano.

Em 2024, aprendemos como transformar um Demo em um software que pudesse operar ao longo do tempo: como lidar com sincronização, privacidade, compatibilidade e falhas; como manter um serviço do qual os usuários reais dependiam; e como assumir a responsabilidade pelos dados que uma pessoa pode acumular ao longo de muitos anos.

Essas capacidades ainda importavam. Eles tornaram MagicGourd mais do que uma Demonstração e nos permitiram permanecer responsáveis para com os usuários existentes, mesmo com a desaceleração do ritmo de novos recursos.

Mas 2025 expôs outra camada de capacidade.

Ainda não éramos bons em transformar uma necessidade em uma definição clara de produto. Não éramos bons em criar uma interface e um fluxo de interação polidos e naturais em pouco tempo. Nem poderíamos equilibrar de forma confiável experiência, funcionalidade, confiabilidade e facilidade de manutenção ao mesmo tempo.

Tínhamos conhecimento em algoritmos e capacidade de engenharia de sistemas. Quando surgia uma ideia, podíamos implementar rapidamente o seu núcleo técnico. Mas tecnologia funcional não significava um produto funcional. A força real do produto significava comprimir muitos julgamentos que restringiam uns aos outros em algo que o usuário considerava simples, claro e completo.

Ao entrarmos no segundo semestre do ano, finalmente admitimos que os recursos de nossos produtos ainda não poderiam apoiar nossa ambição.

Primeiro aprenda como afiar a lâmina

Definimos o segundo semestre do ano como um período para desenvolver capacidades.

A decisão foi difícil. No final do primeiro semestre, havíamos investido muito esforço para entender por que deveríamos atender os clientes com antecedência. No segundo semestre, porém, decidimos parar de apressar cada produto inacabado na frente dos usuários e primeiro aprender como construir bem os produtos.

Superficialmente, isso parecia uma retirada do mercado de volta para dentro da empresa. Mas o problema que queríamos resolver não era um problema que só o mercado pudesse responder.

Os usuários podiam nos dizer se uma necessidade era real, se o produto criava valor e se queriam continuar a usá-lo. Mas, se até nós considerávamos a interface pouco polida, já sabíamos que um fluxo de interação estava incompleto ou que problemas de confiabilidade esconderiam o valor central, entregar o produto aos usuários não produziria informações mais úteis sobre a questão central.

O mercado deveria nos ajudar a responder perguntas desconhecidas, e não a repetir respostas que já conhecíamos.

Então começamos a estudar repetidamente produtos que realmente admirávamos. Detalhamos sua estrutura, design visual e interações, perguntando por que cada detalhe foi tratado de uma maneira específica. Através de estudos minuciosos e reimplementações, transformamos julgamentos que podíamos ver em coisas que nós mesmos fizemos. Em seguida, comparamos as diferenças e tentamos novamente, até entendermos por que esses produtos excelentes pareciam simples, naturais e completos.

O estudo detalhado não se tratava de copiar a superfície de um produto ou de buscar uma resposta que pudéssemos levar inalterada. Era mais como a prática pela qual alguém aprende pintura, música ou caligrafia: primeiro treinar o olho para perceber a diferença, depois deixar a mão alcançá-la gradualmente e só então aplicar essa habilidade a um problema próprio.

A capacidade do produto contém uma grande quantidade de conhecimento tácito como este. Compreender uma ideia, ou mesmo avaliar com precisão o produto de outra pessoa, não significa que possuímos essa capacidade. Somente transformando julgamentos em interfaces, interações e sistemas por meio de repetidas escolhas concretas é que essa capacidade poderia realmente se tornar parte da equipe.

No final do ano, ainda não conseguíamos provar que éramos capazes de construir produtos excelentes de forma consistente. Mas no meio do ano, tudo o que podíamos fazer era sentir vagamente que “este produto não é bom”. No final, poderíamos dividir esse julgamento em questões mais específicas: como a informação deveria ser organizada, como uma interação deveria progredir, como os detalhes visuais deveriam apoiar o todo e como as restrições do sistema afetariam a experiência. Poderíamos então treinar essas habilidades uma por uma por meio de decomposição, estudo minucioso, reimplementação e reconstrução.

Essas mudanças ainda eram apenas resultados da prática interna e não podiam substituir o teste de usuários reais. O que podíamos dizer era que tínhamos começado a formar uma forma mais concreta de praticar e que a distância entre os nossos olhos e as nossas mãos tinha começado a diminuir.

A angariação de fundos não se trata apenas de dinheiro

Olhando para trás, o ponto que Kehan tinha defendido no início do ano estava a ser confirmado, lentamente.

Receber investimento foi importante, mas dinheiro não foi tudo o que MiraclePlus nos deu. A orientação de mentores e as conversas com colegas não se transformariam necessariamente imediatamente em usuários, receitas ou em um produto de sucesso. No final do ano, não poderia dizer que estas relações tivessem produzido resultados diretos. Mas a metáfora da adaga de Peter já havia entrado na forma como avaliamos os produtos todos os dias.

Continuou nos forçando a reexaminar nossos produtos. Sempre que pensei ter entendido, a prática posterior me mostrou que eu havia entendido apenas uma parte.

No início, pensei que isso significava reduzir o vasto segundo cérebro a algo menor. Mais tarde, pensei que pequeno, rápido e atraente significava afiado. Mais tarde ainda, percebi que uma adaga de verdade não funcionava apenas por ser pequena. Ela tinha que concentrar uma experiência completa de produto em um problema específico.

O acelerador não fez a adaga para nós, mas nos ajudou a ver mais cedo por que a coisa em nossas mãos ainda não era uma.

Isso é o que significa dizer que arrecadação de fundos não é apenas uma questão de dinheiro. Pode não fornecer uma resposta imediata, mas pode mudar a forma como fazemos perguntas, nos avaliamos e continuamos aprendendo.

A verdadeira precisão também exige integridade

No final de 2025, meu entendimento de uma adaga era diferente do que era no início do ano.

A compreensão do problema do usuário era a ponta. A interação, a interface e a experiência do produto formavam o fio. A integridade funcional era o corpo da lâmina. A confiabilidade e a facilidade de manutenção eram como o cabo, permitindo que alguém realmente a segurasse e usasse.

Uma única ponta afiada poderia, no máximo, se tornar um demo impressionante. Ainda não era uma adaga que alguém pudesse realmente usar.

Completude não significava colocar tudo no produto. Um canivete suíço pode resolver muitos problemas, mas pode não se aprofundar o suficiente em nenhum deles.

A verdadeira completude significava completar toda a jornada que o usuário precisava em torno de um valor central. Cada parte do produto tinha que apontar para o mesmo problema e dar suporte às outras partes, em vez de usar mais recursos para esconder o fato de que o problema central permanecia sem solução.

Em 2023, deixei SenseTime e pulei no próximo rio. Em 2024, fizemos a cabaça e começamos a entender porque um produto tinha que funcionar com o tempo. Em 2025, queríamos que a magia finalmente aparecesse e também tentamos quebrar o vasto segundo cérebro em uma adaga.

A magia ainda não havia aparecido e Sayso ainda não havia se tornado um produto funcional. Embora agora pudéssemos ver a necessidade, ainda não tínhamos a capacidade de construí-la de forma rápida e adequada.

Mas ao longo do ano, pelo menos passamos a ver com mais precisão o que nos faltava.

Nossa busca por precisão não nos fez abandonar a integridade, a confiabilidade ou a responsabilidade de longo prazo. Também estávamos começando a entender que encontrar os clientes cedo não significava entregar a eles um produto que já sabíamos ser ruim, e que a iteração rápida não significava buscar apenas velocidade de desenvolvimento.

Até hoje, ainda não fabricamos aquela adaga totalmente formada.

Nós apenas começamos a aprender a afiá-la.

Uma ponta por si só não é uma adaga.