A figura abaixo mostra as seções da flexM4i relacionadas com protótipos, que remete para as seções relacionadas com a conexão empresa-startups.

Figura 1402: Seções da flexM4i relacionadas com protótipos (clique na figura para abrir um PDF em outra aba com os links para essas seções)

ocupando posição de destaque nas duas trilhas (figura 420 anterior), embora com papéis distintos.

• Na trilha tecnológica, a POC é o elo forte inicial. Ela tem como objetivo confirmar a viabilidade de um princípio ou tecnologia e demonstrar robustez técnica em condições controladas. Normalmente antecede a criação de protótipos funcionais, mas em alguns casos pode evoluir para um MVP que explore a tecnologia junto a um grupo maior de clientes.
• Na trilha de mercado/usuário, a POC surge sobretudo no relacionamento B2B. É comum que o primeiro contato entre uma startup e uma empresa estabelecida ocorra por meio de uma prova de conceito, que busca validar a solução no ambiente do cliente. Em startups mais maduras, a POC é apresentada após protótipos internos (realizados dentro da startup). Já em fases iniciais, pode ser construída em cooperação com a empresa parceira, inclusive a partir de protótipos de baixa fidelidade.

Dessa forma, a POC desempenha um papel de transição: no campo tecnológico, dá segurança para evoluir para protótipos funcionais; no campo de mercado, estabelece a confiança inicial entre fornecedores (startups) e clientes corporativos no contexto da conexão empresa-startups.

Na prova de conceito (POC – proof of concept) avaliamos a viabilidade técnica de uma ideia ou princípio tecnológico, geralmente em ambiente controlado e limitado.

Já o projeto piloto não é um artefato (por isso é que ele não se encontra na figura 430 introdutória desta seção), mas sim uma fase de teste em ambiente real, aplicada a uma solução funcional. Ele pode se apoiar em resultados de uma POC ou de um MVP, mas não deve ser confundido com nenhum deles.

Grande parte das POCs, especialmente em indústrias, é realizada para criar soluções voltadas à excelência operacional — em processos produtivos, máquinas ou equipamentos. Por isso, a POC costuma ocorrer em ambiente controlado e restrito, enquanto o projeto piloto leva essa solução para o ambiente real de produção, mas ainda sem se confundir com um teste voltado diretamente ao cliente final. Esse percurso está alinhado à trilha tecnológica indicada na figura 430.

Neste contexto, uma POC, se validada, pode evoluir para uma fase piloto e depois para uma fase de implementação em larga escala na empresa, também conhecida como rollout.

Nova trilha da perspectiva da empresa (cliente) que sempre quer testar uma POC

Apesar das duas trilhas apresentadas na figura 430, no caso da POC no contexto da relação entre empresa estabelecida e startups, é comum que exista  uma outra  trilha, da perspectiva da empresa estabelecida (cliente), que se inicia pela POC.

Nesse caso estamos falando de duas perspectivas: da startup e da empresa estabelecida:

• Perspectiva da startup: Pode ser que a tecnologia ou a solução desenvolvida pela startup já esteja madura e tenha passado por diversas etapas consolidadas. Por exemplo, pode ser que a startup tenha desenvolvido a tecnologia / solução a partir de um protótipo de baixa fidelidade; tenha aplicado em alguns clientes como POC para validar o conceito; tenha apresentado ao mercado como MVP e tenha finalizado como um protótipo funcional.
• Perspectiva da empresa estabelecida: É comum que as empresas tratem o relacionamento inicial com a startup testando uma POC, mesmo que a tecnologia ou a solução desenvolvida pela startup já esteja madura, como exemplificamos no caso anterior.

Esse descompasso entre a empresa e a startups traz dificuldades que descrevemos nas seções da flexM4i que tratam da conexão empresa-startups e da comparação entre POC e projeto piloto. 

Repetimos abaixo a figura apresentada na descrição da trilha de mercado / usuário no contexto B2B, que mostra um possível caminho de evolução da POC até a produção. Quando o protótipo funcional atinge maturidade suficiente, ele pode abrir caminho para a fase seguinte — o projeto piloto —, conforme ilustrado na figura a seguir.

Figura 1401: evolução de uma POC, para um projeto piloto para um protótipo até o roll out que culmina com a solução em produção
Fonte: adaptado de Maksimavicius (2017)  

Uma estratégia adotada por startups mais maduras e já especificar no contrato inicial para implementação da “POC” (da perspectiva da empresa cliente), quais são as condições para a passagem para o projeto piloto e para o roll out (implementação ampla na empresa).

Na transformação digital é comum que soluções digitalizadas sejam testadas por meio de POCs.

 A transformação digital atinge todas as áreas das empresas, o que se reflete em todos os processos: desenvolvimento de produtos e serviços, vendas, propaganda, produção, pós-venda etc. Nos estágios iniciais ocorre a digitalização dos processos (informatização e conectividade).

Um exemplo  é o desenvolvimento de uma solução digital na busca por excelência operacional dos processos. Se a solução proposta rodar, significa que o conceito é realizável. 

É comum que as funções de “áreas de inovação” de empresas estabelecidas (corporações) estejam “limitadas” à contratação de startups para melhorar a excelência operacional (aumento de produtividade e/ou diminuição de custos).

Por um lado, essas “áreas” recebem um orçamento (budget) para gastar com POCs. É comum uma estrutura de desenvolvimento de programas de inovação, em que a partir da identificação de desafios específicos das áreas, a área de inovação fica responsável por encontrar soluções que resolvam estes desafios.

Por outro lado, startups com soluções tecnológicas específicas procuram essas empresas para vender POCs e, assim, aperfeiçoar suas ofertas. O segundo caso, exige uma maior negociação e convencimento, visto que dentro de programas de inovação há uma maior clareza do desafio a ser solucionado. 

Essa é a razão pela qual as POCs tornaram-se famosas no relacionamento B2B, ou seja, é a forma preferida de se desenvolver inovações e de se relacionar com startups, principalmente por permitir uma avaliação prévia da solução antes de uma compra efetiva

Segundo o blog da Randon (visitado em 25/9/2024), a POC ajuda a evitar:

• erros graves no funcionamento do serviço (ou na performance do produto) quando já está no mercado;
• desperdício de recursos resolvendo problemas para os quais não há um público-alvo;
• custos extras financeiros com remodelação da base operacional do negócio, especialmente quando a startup tem apenas um produto ou serviço;
• desconhecimento do mercado ou de concorrentes;
• resolução de um problema, mas geração de outros (quando o empreendedor não percebe que criou um gap entre a solução que ele oferece e o que o cliente realmente precisa), entre outros.

Vale ressaltar que a POC exige esforços dos dois lados. Como é um ambiente de teste, a participação da grande corporação principalmente em termos técnicos de execução dentro do ambiente da empresa e feedback dos resultados são fundamentais para que a PoC aconteça.

A figura abaixo mostra as seções da flexM4i que tratam da conexão empresa-startups. Você pode clicar na figura e baixar um pdf que contém os links para essas seções. Em especial, atente para as melhores boas práticas dessa abordagem, que discute, entre outros tópicos, a necessidade de se adaptar os processos para possibilitar a construção de POCs sem prejudicar a startup.

Figura 1280: ilustração das seções relacionadas com a conexão empresa – startup: a seção “Conexão empresa-startup” da perspectiva de uma empresa estabelecida; a seção que apresenta um exemplo de uma “Metodologia para conexão com startups”; e a seção com a compilação de “Boas práticas da conexão com startups” (se você clicar nesta figura, você pode baixar um pdf com os links para as três seções)

Custa desenvolver uma POC. Muitas empresas que se conectam com startups para resolver seus problemas, contratam uma startup inovadora para desenvolver a POC.

Na flexM4i apresentamos 41 boas práticas da conexão empresa-startups. Entre elas destacamos:

• A necessidade de adaptar os processos (e com eles as exigências de conformidade na confecção de contratos e prazos de pagamentos);
• Dimensionar, planejar e definir apoio financeiro e operacional para startups para garantir o apoio ao desenvolvimento de uma POC

Ainda que tenhamos evoluído muito em entender como trabalhar com startups, muitas empresas possuem uma mentalidade “predatória” ao se conectar com startups em um contexto de inovação. Isso ocorre principalmente por exigências tais como os custos de desenvolvimento sem que haja a garantia de contratação posterior do serviço. 

O pior cenário é quando as empresas solicitam POCs de mais de uma startup com o intuito de escolher a solução que mais se encaixa, fazendo com que as que não foram selecionadas sejam responsáveis por todos os custos sem nenhuma contrapartida financeira.. 

Pensando em um cenário em que startups estão em validação, arcar com despesas sem nenhuma receita é um caminho perigoso, que pode “matar” a iniciativa. 

São as empresas que devem arcar pela POCs.

Como padrão de mercado, espera-se que as POCs tenham um valor inferior à contratação do serviço posteriormente, mas o valor cobrado deve pelo menos cobrir os custos de execução. Um contrato jurídico feito por uma assessoria especializada é a melhor forma de assegurar os direitos das startups. 

As vantagens de os custos de uma POC serem assumidos pela empresa contratante são:

• Aumenta o comprometimento das partes:  O pagamento fortalece a responsabilidade mútua entre a empresa e a startup, reduzindo riscos de desinteresse ou atrasos.
• Formaliza o envolvimento da empresa: Cria um ambiente mais estruturado e profissional para testar e validar a solução.
• Demanda um planejamento mais rigoroso:  Gera metas e datas definidas, assim como a alocação adequada de recursos (pessoas que devem participar).
• Reduz o risco de testes inconclusivos:  A estrutura proporcionada por uma PoC paga eleva a qualidade do processo e aumenta a chance de evolução para piloto e implementação.
• Demonstra o interesse real da empresa: Quando uma empresa paga por uma POC, a startup percebe que há intenção genuína em adotar a solução, dando sinais positivos ao mercado e à startup.
• Ajuda na validação da proposta de valor da startup: Permite à startup testar seu modelo de negócio com mais robustez, acelerando sua entrada no mercado.
• Fortalece o relacionamento e a chance de parceria futura:  Estabelece bases mais sólidas para uma relação de longo prazo entre startup e empresa.
• Evita o baixo comprometimento em projetos gratuitos:  A ausência de compromisso financeiro em PoCs gratuitas pode comprometer resultados e desestimular a continuidade.

No contexto dos níveis de maturidade da tecnologia (TRL – Technology readiness levels), a prova de conceito tem um outro significado. 

No nível TRL 3, a “prova de conceito” pode envolver modelos e simulações ou testes iniciais em laboratório, mas não é ainda o mesmo que um protótipo funcional, que surge nos TRLs posteriores.

O protótipo mais desenvolvido aparece no TRL 4 e além, onde começa a integração de componentes em ambientes de teste mais controlados.

O blog da empresa Randon apresenta os conceitos principais sobre POC.

O verbete da wikipedia em inglês mostra a prática de POC em alguns segmentos de mercado.

A descrição do apoio está relacionada com todas as seções sobre protótipos.

A primeira versão desta seção foi escrita sem apoio do chatGPT. A versão atual foi completada com o apoio do chatGPT 4.o, que foi utilizado para organizar os conteúdos encontrados em publicações citadas. Nenhum conteúdo foi criado exclusivamente pelo chatGPT. Sempre foram fornecidos trechos de fontes de referência com instruções de como deveriam ser combinadas e organizadas. Mais de 40 iterações foram necessárias para se obter a versão que foi editada pelo autor desta seção.

Conforme novas referências foram sendo conhecidas, novas versões foram realizadas sem apoio do chatGPT. Partes desta seção foram corrigidas, modificadas e novos tópicos foram inseridos, pelo autor. 

Após 10 meses da primeira versão, a revisão desta seção foi realizada adicionando novas referências, além da revisão da Isabela Simões na seção sobre Prova de Conceito (POC). Nessa fase foi utilizada a versão 5.0 do chatGPT.

Além disso, foi incorporado nesta seção um resumo de um vídeo do YouTube (tópico “Por que 90% dos MVPs falham”). Este vídeo foi resumido pelo Google NotebookLM.

A criação desta seção teve a duração de mais de 80 horas, com 230 interações “ser humano – agente de IA” (ChatGPT)”, realizadas ao longo de duas semanas. A conversa resultou em mais de 440 páginas de interação e cerca de 119 mil palavras geradas. A extensão do conteúdo deveu-se, em grande parte, à necessidade de construir, revisar e ajustar cada trecho da versão anterior da seção.

O foco delimitar os conceitos, que muitas vezes eram antagônicos em diferentes publicações procurando equilibrar profundidade teórica e adequação prática.

Após algumas interações, foram definidos novos tópicos do sumário da seção, a partir do sumário anterior. Iniciou-se então uma revisão conjunta “ser humano – agente de IA” de cada tópico.

Em nenhum momento o autor solicitou que o ChatGPT gerasse respostas com base em seus conhecimentos gerais. Todo o conteúdo foi elaborado a partir de materiais fornecidos, trechos comentados ou instruções precisas baseadas em análises do autor. Os textos produzidos passaram por diversas iterações, com o autor sugerindo ajustes, criticando formulações e, ao final, realizando pessoalmente a edição final de todos os blocos de conteúdo.

O autor conferiu sempre se os textos gerados pelo ChatGPT estavam alinhados com as fontes originais. Quando surgiam inconsistências ou dúvidas, ele fazia a checagem diretamente nas publicações de referência antes de aprovar qualquer trecho.

Nesses momentos, para garantir que o chatGPT estava utilizando as fontes fornecidas, já que ele possui limitações para indicar de onde ele tirou cada trecho de texto avaliado, utilizamos em conjunto o NotebookLM da Google para conferir os trechos das fontes utilizadas.

Esse processo exigiu iterações intensas e repetitivas, com refinamento textual, ajustes conceituais e reorganização de argumentos. Em vários momentos, versões intermediárias foram reanalisadas no próprio ChatGPT, que indicava melhorias, tensionamentos ou oportunidades de aprofundamento. O autor avaliava criticamente essas sugestões, nem sempre concordando, e frequentemente propunha soluções alternativas, mantendo sempre o controle final da redação.

Foi solicitado ao ChatGPT que não aceitasse automaticamente as propostas do autor, mas que realizasse uma análise crítica, sugerisse alternativas e propusesse reformulações embasadas nos conteúdos utilizados. Nesses momentos, o próprio chatGPT selecionava um modelo que demorava mais para responder. Quando aplicável, o autor indicava práticas baseadas em sua própria experiência, e o ChatGPT as incorporava, respeitando a distinção entre conteúdo empírico e referenciado. Nesses casos, o autor “ditava” para o chatGPT formular as frases, que posteriormente foram melhoradas pelo autor..

Durante todo o processo, foi enfatizado que o ChatGPT não deveria reescrever blocos inteiros automaticamente, mas sim identificar pontos de melhoria e sugerir correções localizadas, com justificativas. A edição final foi sempre realizada manualmente pelo autor desta seção.

Essas referências estão relacionadas com todas as seções sobre protótipos.

Altersoft (2022) Functional Prototype: How to Iterate with Your Software Product. Disponível em: https://www.altexsoft.com/blog/functional-prototype/  Recuperado em: 26 setembro 2024.

Bland, D. J., & Osterwalder, A. (2019). Testing business ideas: A field guide for rapid experimentation. Hoboken: John Wiley & Sons.  

Blank, S., & Dorf, B. (2012). The startup owner's manual: The step-by-step guide for building a great company. John Wiley & Sons.

Dam, R. F. & Teo, Y. S. (2024, February 21). 5 Common Low-Fidelity Prototypes and Their Best Practices. Interaction Design Foundation - IxDF. https://www.interaction-design.org/literature/article/prototyping-learn-eight-common-methods-and-best-practices 

Ries, E. (2011). The lean startup. New York: Crown Business. 

Robot Mascot (2018). 18 types of minimum viable product (MVP) that won’t break the bank. Disponível em: https://www.robotmascot.co.uk/blog/18-types-of-minimum-viable-product/  Recuperado em: 26 setembro 2024.

Sparkmate (2023) Functional Prototyping: How the Iteration Process Goes. How to build a functional prototype and the road to building a MVP. Disponível em: https://www.sparkmate.com/blog/functional-prototyping  Recuperado em: 26 setembro 2024.

Ulrich, Karl T.; Eppinger, Steven D.; Yang, Maria (2019) Product Design and Development. 7th. ed. New York: McGraw Hill.

Uxpin, T. (2024). Examples of Prototypes – From Low-Fidelity to High-Fidelity Prototypes. https://www.uxpin.com/studio/blog/prototype-examples/