Abaixo, você tem uma lista de outros artigos similares a este, onde tento aprender um pouco sobre a estratégia de negócio e de produto de empresas com produtos digitais que utilizamos todo dia.
- Estratégia de negócio e produto do Spotify
- Estratégia de negócio e de produto do Slack
- Estratégia de Negócio e Produto do Roblox
E tem um pedaço mais polêmico depois do artigo principal.
Introdução
Eu não acho o Figma um produto inovador. Muitos dos seus fundamentos foram criados em softwares anteriores, como o Fireworks, que já tentava resolver problemas de design de interface conectados às necessidades técnicas de implementação.
Mas como qualquer solução inovadora, se ela não é “inventada” no tempo certo, acaba desaparecendo. O Google Glass e o próprio Fireworks são exemplos clássicos. Produtos que querem inovar um mercado precisam ir com calma, porque o mercado pode não estar preparado para aquela inovação específica.
Nesse caso, quem faz o produto precisa direcionar as pessoas que formam aquele mercado a enxergarem o que eles estão enxergando. É um processo lento que precisa respeitar todas as fases de formação de maturidade.
Gráfico da pesquisa DESIGN TOOL SURVEY 2024.
Nesse caso, quem faz o produto precisa direcionar as pessoas que formam aquele mercado, a enxergarem o que eles estão enxergando. É um processo lento e que precisa respeitar todas as fases dessa formação de maturidade. O Google Glass não conseguiu. Podemos enumerar vários problemas, mas vou citar só um: privacidade ainda era um assunto difícil na época.
Definitivamente as pessoas não estavam preparadas para lidar com outras pessoas com óculos que poderiam tirar fotos, filmar, gravar sem você saber... Pois é. Hoje, isso aí é praticamente comum.
Na minha opinião, o Figma tem conseguido direcinar as pessoas e o mercado com muita maestria. Estão construindo uma plataforma que expõe cada vez mais os gaps e ineficiências existentes no fluxo de construção de produto, principalmente quando envolve todos os problemas dentro da fronteira entre os mundos do design e técnico.
É por isso que ele conseguiu se tornar o gigante que é atualmente. E não foi por causa do pitch que o Dylan Field fazia para os investidores. Vídeo aí em cima, você consegue ver que o pitch é horrível. Não mostra números, não mostra a tela do produto, não fala do produto especificamente... É assunto para outro artigo.
O Figma se tornou grande por que eles começaram mudar o processo por meio do produto/plataforma que criaram.
Os números que impressionam: a máquina de gerar receita
Crescimento Exponencial
- Receita anual 2024: US$ 749 milhões - Fonte – TechCrunch
- Receita rolling 12 meses (R12M até Q1 2025): US$ 821 milhões - Fonte – The Deep Dive
- Crescimento YoY 2024: +48% - Fonte – TechCrunch
- Crescimento Q1 2025 YoY: +46% - Fonte – Barron’s
- Margem bruta: 91% - Fonte – OnlyCFO
- Rule of 40: 64% (46% de crescimento + 18% de margem operacional ajustada) - Fonte – The Deep Dive
IPO 2025: O grande momento
IPO no segundo semestre de 2025
- S-1 protocolado: Julho de 2025
- Fonte – SEC S-1 no Edgar
- Fonte – Barron’s
- Ticker: "FIG" na NYSE - Fonte – Renaissance Capital
- Valuation em último tender offer (2024): US$ 12.5 bilhões - Fonte – Forge Global
- Valuation esperado no IPO: Entre US$ 13.7B e US$ 16.4B
- Captação esperada: até US$ 1.03 bilhão oficialmente, podendo chegar a US$ 1.5 bilhão em projeções otimistas - Fonte – Renaissance Capital
- Underwriters: Morgan Stanley, Goldman Sachs, Allen & Co., J.P. Morgan - Fonte – Renaissance Capital
Métricas Operacionais: O Freemium que funciona
- Base de usuários ativos: mais de 13 milhões de MAUs (Monthly Active Users)
- Clientes enterprise > US$ 1M ARR: dezenas reportados, mas número exato de +1.000 > US$ 100K/ano não foi confirmado publicamente - Fonte – Discussion Fool
- Net Dollar Retention (NDR): 132% em Q1 2025 - Fonte – Mostly Metrics
- Gross Margin: 90%+ consistentemente - Fonte – The Deep Dive
Aspiração vencedora: democratizar o design
O Figma trabalha em um mercado que por si só já é inspirador. Eles estão realmente ajudando o product designer a se tornar mais relevante. Product Design é uma disciplina que se perdeu durante um tempo no próprio reflexo (e nem foi por causa da Nêmesis). Inventou tantos nomes e sobrenomes para tantas divisões e subdivisões, se perdendo demais do que eles poderiam ser.
A aspiração vencedora do Figma é simples de entender, mas ambiciosa de executar: "make design accessible to all". Não é só para quem tem diploma de design ou sabe usar Photoshop desde criança. Eles querem quebrar as barreiras entre quem cria e quem constrói produtos digitais. E não foi sempre assim - a visão original era ainda mais audaciosa: "eliminate the gap between imagination and reality". Dylan Field conta que essa era a visão inicial quando ele tentou explicar para investidores em 2013. Era abstrato demais, confuso demais. Então eles mudaram para algo mais concreto, mas não menos impactante.
In today’s world full of inequality, the power to create digitally equals economic mobility. It’s imperative that we reduce barriers to creation so that more people can find opportunity and fulfillment. At Figma, our mission is to make design accessible to everyone — on any given day, you’ll often find us twisting ourselves in knots trying to give users more power while keeping our software simple. Why I'm Leading Warp's Series A
O que o Figma fez foi pegar um processo que era exclusivo - exigia Mac caro, software proprietário, conhecimento técnico específico - e tornar acessível para qualquer pessoa com um browser. "Internet native software embodies values like collaboration, transparency, and access", explica Dylan.
Daí que quando eles apostaram tudo no browser, não estavam só fazendo uma escolha técnica, estavam fazendo uma escolha lógica: a definição da experiência do produto não acontece apenas na tela do Photoshop e nem era responsabilidade exclusiva do designer, mas extrapolava para desenvolvedores e outros membros do time.
Se validar a interface em si já é um processo terrível, imagina validar isso em conjunto com o funcionamento do produto? Quando tentamos fazer times de diferentes disciplinas trabalharem em conjunto, um processo que “obriga” a colaboração é importante. Mas só consegue ser eficiente se as ferramentas facilitarem esse fluxo. Não há processo de design que sobreviva quando o designer precisa salvar uma penca de JPGs e enviar por email/slack/whatsapp para aprovação.
Deixar o design acessível não é uma visão ideológica, mas resolver uma ineficiência real e antiga do mercado. Embora não tenham sido os únicos a tentar isso no passado, foram os únicos que conseguiram dar uma resposta coerente dentro de um mesmo produto.
E é aí que entra onde o Figma resolveu jogar.
Onde jogar: o caos que a gente chamava de processo
Antes do Figma, o que chamávamos de "processo de design" era, na verdade, um festival de ineficiência disfarçado de metodologia.
Imagina isso: Designer abre o Photoshop (ou Sketch, se fosse mais antenado na época), cria uma interface linda, salva um PNG, manda no Slack para o dev. O cara olha a imagem, tenta adivinhar as medidas, pergunta sobre estados de hover, não recebe resposta porque o designer já estava em outra, e implementa do jeito que dá. Resultado? Aquela briga clássica de "não era isso que eu desenhei" versus "você não especificou direito".
E isso nos melhores dias, quando dava certo.
O inferno da fragmentação de ferramentas
Como conta Shawn Lan, Head of Design do Zoom: "Para um único projeto, fazíamos revisões para várias ferramentas de 10 a 20 vezes e depois tínhamos que gerenciar reviews através de múltiplas ferramentas, versões e stakeholders". Era um ciclo vicioso: Sketch para design, InVision ou Framer para prototipagem, Zeplin para handoff de desenvolvimento. Cada mudança significava sincronizar arquivos entre todas essas ferramentas separadas.
A equipe do Flipboard, onde Dylan Field estagiou, "gastava horas no controle de versão e arquivos — mas ainda assim tinha dificuldades com colaboração. Designers iam para seus próprios cantos por alguns dias e emergiam com novos designs, ao invés de trazer todo mundo junto. Era como lidar com arquivos do Microsoft Word na era do Google Docs" .
O problema não era só técnico ou processual, era estrutural. Você não conseguia ter um processo eficiente quando cada etapa exigia uma ferramenta diferente. Era como tentar dirigir um carro onde o volante fica em uma cidade, o acelerador em outra, e o freio numa terceira.
A guerra silenciosa entre design e desenvolvimento
O drama real acontecia na fronteira entre design e código. "Se você quisesse compartilhar um design que estava no Sketch, você fazia um screenshot e enviava, mas nesse ponto, estava fora de contexto", explica Lan.
Era uma cadeia de degradação da informação. O designer criava uma interface no Photoshop com layers organizados de um jeito que só ele entendia (e era só ele mesmo, tá louco... tinha briga dentro do próprio time de design). Exportava algumas telas estáticas. O desenvolvedor recebia essas imagens e tentava deduzir:
- Qual a margem exata entre os elementos?
- Como fica o botão quando o usuário passa o mouse por cima?
- E se o texto for maior que o esperado?
- Qual a fonte exata e o tamanho?
- Quais as cores em hexadecimal?
E até o Sketch, que era o melhor software de design de produto da época, não conseguia resolver os problemas mais básicos do processo. Com o Divar comentava:
