Como unificar produtos digitais em uma plataforma

Quando cada produto exige que o cliente comece de novo

Uma empresa pode ter vários produtos complementares e ainda oferecer uma experiência fragmentada. O cliente repete cadastros, administra credenciais diferentes e precisa entender uma nova lógica a cada contratação.

Por dentro, essa separação também pesa: equipes mantêm integrações distintas, o suporte precisa conhecer caminhos diferentes e a área comercial tem dificuldade para apresentar o conjunto da oferta.

Unificar produtos digitais envolve conectar acesso, planos, consumo, cobrança e documentação. O trabalho começa pela jornada que esses serviços precisam compartilhar e pelas dependências dos sistemas que já estão em operação.

Uma plataforma para conectar serviços de confiança digital

O projeto foi realizado para uma empresa de serviços de confiança digital, incluindo assinatura eletrônica, verificação e certificação. No início do projeto, seus produtos tinham contas, logins, documentações e experiências separados. Quem usava mais de um serviço precisava atravessar essas diferenças.

A Origami Lab trabalhou com as equipes do cliente no discovery e no desenvolvimento de uma plataforma para conectar essa oferta. A proposta reuniu uma experiência de acesso compartilhada, contratação de serviços, acompanhamento de consumo e recursos para quem integra as APIs.

Começar pelas pessoas que precisam usar a plataforma

A descoberta combinou entrevistas, mapeamento dos sistemas existentes e um workshop presencial de quatro dias. Três grupos multidisciplinares desenharam as jornadas de quem gerencia a plataforma, de quem integra a API e de quem envia documentos para assinatura.

Essas jornadas deram origem a uma prototipação validada com os times e a diretoria. O alinhamento ajudou a transformar uma visão de plataforma em decisões sobre acesso, contratação e uso.

Uma hipótese orientou a priorização: permitir que uma pessoa criasse uma conta gratuita e experimentasse o serviço com poucas etapas antes de contratar. O desenvolvimento começou pelo trial e pelo uso self-service. Outras capacidades foram adicionadas em ciclos seguintes.

Uma base comum, construída em entregas sucessivas

O desenvolvimento foi organizado em 11 sprints de 15 dias, com revisão das entregas a cada ciclo e encontros de estratégia com o cliente. A construção avançou por três frentes:

1. Disponibilizar os primeiros serviços

   Infraestrutura, identidade e acesso, autenticação multifator, verificação de documentos, assinatura, backoffice e plano de experimentação.

2. Conectar contratação e operação comercial

   Compra de créditos, pagamento, modalidades de pós-pago, integração de contas e planos com o legado e conexão com o CRM.

3. Organizar a experiência de integração

   Portal para desenvolvedores, acesso às chaves de homologação e produção e documentação da API de assinatura.

Os sistemas existentes continuaram impondo dependências. Por isso, o escopo e a ordem das entregas foram refinados junto à equipe do cliente conforme o desenvolvimento avançava. Revisão técnica, testes e critérios de conclusão passaram a fazer parte da rotina de cada sprint.

Essa coordenação entre produto e integração de sistemas é parte central do trabalho: cada nova capacidade precisa encontrar seu lugar numa operação que já existe.

O que os marcos e os testes mostram

Primeiro uso da API em 11 minutos, em média

Um teste cronometrado com 15 desenvolvedores de diferentes níveis, sem contato prévio com a plataforma, registrou média de 11 minutos até o primeiro “Hello World”. A medição foi conduzida durante as sprints 9 e 10.

O indicador observa a experiência inicial de quem começa a usar a API. A meta do projeto era concluir esse primeiro passo em menos de sete dias; esse prazo era uma meta, não uma medição anterior. O resultado não representa o tempo necessário para integrar um sistema empresarial completo.

Primeira entrada em produção em 100 dias corridos

A plataforma entrou em produção em maio de 2026, 100 dias corridos após o início do desenvolvimento. O acesso inicial permitiu uso real enquanto o trabalho nas demais capacidades continuava. Esse marco não corresponde à duração total do projeto, que também incluiu descoberta e transferência de conhecimento.

Conhecimento transferido para seis áreas

Nos 20 dias finais, a transferência envolveu Customer Success, Comercial, Engenharia de Software e Arquitetura, Produto, Suporte e Infraestrutura. Cada área recebeu treinamento, espaço para dúvidas e materiais de utilização da plataforma.

A entrega incluiu documentação técnica, guias e um material executivo com a organização do conhecimento gerado. Também foram entregues recursos de medição de uso e acompanhamento comercial, criando condições para a empresa acompanhar a evolução da plataforma.

O que levar para um projeto de unificação

• Mapear jornadas e dependências em conjunto. A experiência desejada precisa ser discutida com quem conhece os sistemas que vão sustentá-la.
• Escolher um primeiro percurso completo. Cadastro, experimentação e uso de um serviço podem orientar a primeira entrega, enquanto outras capacidades evoluem.
• Medir uma tarefa concreta. O primeiro uso de uma API oferece um recorte observável da experiência de integração.
• Planejar a passagem para quem vai operar. Comercial, suporte, produto e engenharia precisam de conhecimento para continuar o trabalho depois da entrega.

Essas escolhas ajudam a avaliar o que precisa ser compartilhado entre produtos e onde faz sentido investir em desenvolvimento de software sob medida. O desenho depende da operação, dos sistemas existentes e das jornadas que a empresa quer tornar possíveis.

Perguntas sobre unificação de produtos digitais