Às vezes a solução mais inteligente não é a que você cria do zero.

Aprendi isso da forma mais prática possível: com um prazo real, um contrato que cobrava uma funcionalidade que não existia, e um stakeholder esperando uma resposta.

Deixa eu contar o que aconteceu.

O contexto

Eu fui PM de um produto educacional voltado pra preparação pro ENEM. A plataforma tinha funcionalidades que eu gostava muito de trabalhar: simulados personalizados com IA, correção de redação instantânea, scoring de habilidades por tópico. Era um produto que resolvia problemas reais dos alunos.

A empresa atendia mercados B2B e B2Gov. E foi justamente um contrato B2Gov que trouxe o problema.

O maior contrato em potencial da empresa, com a Secretaria de Educação do Estado de São Paulo, tinha uma cláusula específica: a plataforma precisava oferecer videoaulas cobrindo toda a grade de tópicos do ENEM.

Detalhe: essa funcionalidade não existia.

O impasse

A gente era uma startup de tecnologia. Não tínhamos time de professores, não tínhamos orçamento pra contratar docentes e, principalmente, não tínhamos tempo pra gravar um acervo inteiro de videoaulas.

A primeira tentativa foi com IA. O time de conteúdo rodou um piloto: criavam os slides e o roteiro, e a IA gerava o voiceover. Parecia razoável no papel.

Na prática, não funcionou bem o suficiente. Isso foi antes do NotebookLM virar o que é hoje, então os modelos não estavam tão afiados. O conteúdo educacional em si era bom, mas os slides e principalmente o voiceover ficaram aquém do esperado. Além disso, escalar aquilo demandaria um esforço enorme do time de conteudistas, fora os custos de tokens em plataformas de IA. Colocando na balança entrega versus prazo do cliente, ficou claro: não daria tempo.

A pergunta certa

Foi aí que parei e fiz a pergunta que devia ter feito antes: a gente precisa construir isso ou precisa entregar isso?

Build / Buy / Partner é um dos frameworks mais clássicos do repertório de produto e inovação. E é exatamente nesses momentos de pressão que ele faz mais sentido.

Build: criar do zero. Descartado, já explicamos o porquê.

Buy: comprar uma solução pronta. Possível, mas exigiria negociação de licença, integração técnica, e ainda assim um custo fixo considerável antes de saber se os alunos iam usar muito ou pouco o conteúdo.

Partner: fechar uma parceria com quem já tinha o que precisávamos.

Fizemos uma varredura de empresas de educação pra ENEM com acervos de videoaulas disponíveis. Encontramos um parceiro cujo conteúdo atendia às requisições do contrato. Fechamos uma parceria em que o conteúdo deles seria disponibilizado na nossa plataforma e o repasse financeiro seria proporcional às views dos alunos, mês a mês.

Isso resolveu dois problemas de uma vez. Entregamos a funcionalidade rápido e a estrutura de revenue foi justa pra ambos os lados: em vez de um valor fixo de licença num cenário de total incerteza sobre o engajamento real dos alunos com os vídeos (afinal, era uma feature obrigatória por contrato, mas ninguém sabia ainda se os estudantes usariam de verdade), a gente pagava de acordo com o uso real. Sem tiro no pé financeiro pra nenhum dos dois lados.

A PoC funcional

Decidido o que entregar, eu precisava mostrar. Não era suficiente descrever em texto ou mandar um Figma com telas estáticas.

Construí uma PoC funcional usando o v0 e subi direto na Vercel. A interface simulava como a funcionalidade de videoaulas ficaria dentro da experiência da plataforma, incluindo navegação, filtros por matéria, e a tela do player com título e descrição do conteúdo.

Apresentei pras áreas de negócio. Os feedbacks vieram rápido porque as pessoas conseguiam interagir, clicar, sentir o produto. O buy-in foi muito mais fácil de conseguir do que seria com um documento de requisitos ou um wireframe que exigisse imaginação.

E tem mais: meu conhecimento de arquitetura de software fez diferença na hora do handoff pro time de devs. Eles conseguiram reaproveitar parte do código e da lógica da PoC diretamente no app de produção, o que reduziu o tempo de entrega e garantiu que a plataforma estaria em conformidade com os itens da licitação.

O que virou feature

A solução que nasceu pra atender um cliente específico virou produto.

O time de comercial passou a usar a funcionalidade de videoaulas como argumento de venda e como resposta pra objeções de clientes em potencial. Clientes atuais receberam a feature como upgrade gratuito, reforçando o posicionamento de que a plataforma evolui junto com eles.

O que ficou comigo

Tenho alguns aprendizados que quero destacar, porque acho que valem pra qualquer PM ou pessoa de inovação:

O pensamento precisa ser estratégico pra encontrar saídas rápidas. Não é sobre fazer o mínimo. É sobre fazer o certo dentro das restrições que existem.

Build / Buy / Partner não é conceito de livro. É uma pergunta real que você deveria fazer sempre que uma nova demanda aparece.

Uma PoC funcional vale mais que mil palavras numa reunião de stakeholders. Se você consegue mostrar como vai funcionar, o entendimento acelera e o alinhamento acontece mais rápido.

Ter pelo menos uma base de conhecimento técnico muda o jogo na sua relação com o time de desenvolvimento. Não precisa ser dev pra conversar de igual pra igual com devs. Mas precisa entender o suficiente pra ser levado a sério.

Leia o contrato. Com cuidado. Esse impasse poderia ter sido evitado se mais pessoas tivessem olhado pro contrato com atenção antes de fechar o negócio. (Essa dói um pouco, mas é real.)

E por fim: pense sempre no revenue. A decisão de fazer o repasse por views e não por um valor fixo foi estratégica. Em cenários de incerteza sobre engajamento, estruturas variáveis protegem os dois lados.

Às vezes a solução mais inteligente é a que você busca fora, negocia bem e entrega rápido.